The Craftsmanship of Code

Last week my sister accused me of being a snob. That stung in that special way reserved for jabs that are true; that you wouldn’t change if you could; and that you wish other people wouldn’t notice. In this case I had apparently gagged raised an eyebrow when she told me about her new desk from Ikea.

“Ikea makes schlock,” I said.

“Ikea makes fun, well designed furniture,” she said.

“Ikea makes furniture that will pack flat and not take too much space in the garbage truck in three years when it’s curbed,” I said.

“Ok, so tell me what Good Furniture is like,” she said.

“Um…,” I said.

“Peh.” she said, and threw a grape at me.

Later, I took her to a local furniture gallery, where we looked at some exquisite handcrafted furniture in the Krenov style. “OK,” she said, “I get it. But you’re still a snob.”

Craftsmanship is like that. It’s difficult to pin down with labels, but it’s evident when you see it. Its absence is also evident. And once exposed to true craftsmanship, it’s hard to be satisfied with anything else, no matter how flat it packs.

Craftsmanship in Programming

There’s currently a schism in the software developer community around the issue of craftsmanship. My degree is in Computer Engineering with a software stream, and the philosophy there was definitely that “craftsmanship” was a dangerous and juvenile concept in software. You don’t want the guy building a bridge to be a “craftsman”, you want him to know the math. Why is software any different? Gather the requirements using ISO certified processes; identify and mitigate risks; design; develop; test; lather; rinse; repeat.

On the opposite side of the continuum are folks who spend a Saturday night bar session debating the aesthetics of various iterator constructions, look up, and notice it’s Tuesday. Like all sensitive artists, these folks tend to move around a bit with the fashion of the day (“Oh, puhleeze. Closures are so 2005.”) and engage in self-indulgent behavior that would get you ostracized if you weren’t wearing a beret. They’re also more fun to hang out with than the bankers.

So is software development craftsmanship? Is it engineering? I think this is an important question, because its answer defines what it means to be an excellent programmer. The most balanced discussion I’ve come across is Joel Spolsky’s discussion on programming as Design. He argues that beautiful code, which we often call craftsmanship, is actually a matter of good design – design in the “wow, that’s a beautiful bridge” sense. His essay is excellent, but I think it is incomplete. Redefining craftsmanship in terms of the external qualities of the product is enlightening, but it’s not everything. It doesn’t explain why some code is more aesthetically excellent than other code. It doesn’t explain why the recursive function that Jamie wrote is so much sweeter than the unwrapped for loop that Frank churned out. Frank’s is even 20ms faster! But it’s crap anyhow.

Slow Down Here

So, here’s the meat of this essay: if you’re skimming, slow down for just a second. I’ll tell you when you can speed up again. Here’s the thing: this debate is not new, and it wasn’t invented by computer programmers. Back in the day, prior to the industrial revolution, there was no debate about whether something was craftsmanship: Everything was crafted, it was just crafted well or crafted poorly. During the mid 19th century, furniture began to be pumped out by factories using mass production techniques. This was good for most people, who could now afford a chair instead of the stump they hauled inside, but bad for craftsmen, who watched traditional knowledge and techniques disappear. The product was also inferior. The “Craftsman” style of furniture was a direct response to mass-produced furniture, as idealists formed communes to produce high quality, honest goods using traditional techniques. (In one of history’s better ironies, the only place you can now buy Craftsman furniture is Wal*Mart and Costco.)

In the mid 20th century mass produced furniture, pottery, wood bowls, etc. were the norm. Yet people were still hand making these items, and consumers often preferred the hand made articles even if they were functionally equivalent. “Hand Made” has become a badge of quality, even if human hands are far less accurate than water jets when cutting furniture joints. People debated whether it was sentimentality; marketing; or something else. Until one David Pye, a professor at the London College of Art, published The Nature and Art of Workmanship. This book is a must-read for everyone who believes that software is more than an assembly of components, simply a alternative view of the requirements. It provides excellent and deep coverage of what we mean by “craftsmanship”, and its lessons will make you a better programmer.

Skimmers can speed up again. After you buy the book.

OK, Speed Up Again

Although there are many lessons in Pye’s book, there are two key theses I’ll highlight here in order to add to Joel’s assertion that software craftsmanship is design.

1. The Workmanship of Risk

Pye argued that craftsmanship was not a binary thing that was present or not in an object. One way to think about craftsmanship was with relation to the risk of the operation. What he means by risk is the proximity of the craftsman to the fate of the product, or the extent to which the craftsman’s skills will directly impact the fate of the product. For example, cutting a piece of wood with a computer controlled router has almost no risk associated with the craftsman. Cutting it with a table saw has more risk: a slip in feeding the wood could ruin the workpiece. Cutting it with a wide handsaw has yet more risk, while carving with a chisel carries the most risk of all – the entire operation is unguided by anything except the makers’ hand and skill.

It isn’t hard to see an analogy in programming. One comes from tools. A programmer using a visual builder and hooking up components using VB has little risk: there may be a bug in the tool, or some misspellings, but most likely the program will run as expected. Compare that to programming in assembler, where it is man and machine. One slip, one transposed digit and the program crashes, probably during the demo.

Nobody programs in assembler of course, just as nobody cuts a plank to width with a chisel. But somehow we know that the programmer who slips effortlessly between C and Ruby, simply choosing the best tool for the job, is more of a craftsman than the VB-or-bust guy in the basement. The former is more willing to accept the risk of his craft. He has the confidence and the ability to pick up the chisel when he needs it, and he does not need to design his furniture around the capabilities of the computer router.

2. The scaling of aesthetics

The second thesis of Pye’s that has immediate relevance to programming is the scaling of aesthetics. Consider a skyscraper of exceptional beauty. When you are one kilometer away, you notice its shape, its overall form, and perhaps its relationship to its geography. Come closer, to 500 meters, and the overall form that was beautiful at 1km fades away. But in a seamless progression, it is replaced by the relationship of base to the tower; by the shape of the windows and the color and shadows of the building’s facets. Come in to 100 meters and you can no longer see the overall form or the way the windows gradually narrow as they reach the top; but you can see the form of the facade and the shape of the front entrance, and the way the glass faces to encourage your eye to sweep across the ground level. Come up to one meter and all of that dissolves, but is replaced by the texture of the surfaces and the choices of materials.

The point is that the architect did not consider beauty only at one scale; as one changes scale, different scales of aesthetics emerge, gradually replacing one another in appropriate sequence. No scale is out of place, and every scale has its own merits. The good design morphs as you approach and retreat, surprising and delighting you with new aspects of its beauty.

Consider software. The furthest you can stand from software is as a user, and here you see the design of the user interface; the choices of color, and how well the software anticipates the user’s needs and actions. This is the craftsmanship that Joel describes, and he’s spot on.

But as a programmer, you can move in. You can see the overall architecture of the software, the lack of coupling or spurious dependencies. Move in further and you can see the way the programmer used only RESTful calls in his data access layer, and the grace that affords to the module. Move in again and you’ll see Jamie’s recursive algorithm: only ten line, with symmetrical identation, looking like a wave on the page. But move in to one meter and you see the texture of that call; the multilayered complexity of the recursion that enables the simplicity at another scale.

The craftsmanship is in the unified whole, the way one scale of aesthetic seamlessly blends into the next.

Programming IS Craft

My conclusion, of course, is that creating software is craftsmanship. Not in the way it’s usually meant, which is often just a catch-all word for “it’s not exactly science, but not exactly art either”. Programming can be craftsmanship in a deep, profound way. Not everyone who creates software is a craftsman, and nor should they be: if we didn’t have mass-produced furniture I’d be writing this sitting cross-legged on the floor in my thatch hut. But there is a place for craftsmanship in software, and once you’ve seen it, you may never be satisfied with code generators again.

The Maestro Set-up

There’s been a lot of chat about the Subway Maestro, some of it wistfully sad, most of it implicitly self-congratulatory, and all of it lamenting the sorry state of mankind.

For the four of you who missed the story, Joshua Bell, who is the current Best Violinist Ever, did a stunt where he spent a few hours busking in a Washington subway station. The story is that few people stopped to listen, and this guy, who probably gets to keep the limousine they use to drive him to Carnegie Hall each Saturday, made about $35 bucks in change. The Washington Post showed a video of people hurrying by as Joshua played, paying special attention to the mom dragging her fascinated 3-year-old away and the career table-busser who risked his job to get closer. But the masses of educated, government workers hurried on by. What a situation we’ve made, what a depth we’ve plumbed, how we’ve civilized civilization right out of ourselves.

What a crock.

In Blink, Malcolm Gladwell talks about how the expert eye can recognize quality or authenticity is something, seemingly by intuition: they glance at something, and they simply know. But he points out that those people rarely know exactly why they recognize authenticity, cannot pass the knowledge on to others, and, most importantly, that ability takes years and years of experience. And years of experience doesn’t mean you’ll have it: even among the veterans in a field, the expert eye is rare.

Now consider the passers-by in the subway station. They have their own internal context. There is often a busker at that spot, and there is one today as well — nothing out of the ordinary to alert them or cause them to pay attention. They are in a crowd, they have a mission, and they are close enough to Mr. Bell to hear him clearly for around five seconds, ten if they’re eating a sandwich while walking.

Many of these people may enjoy classical music, but they are probably not experts. Certainly, they likely have a limited exposure to various violinists, and would be hard pressed to name one, much less tell two professionals apart. And yet we’re surprised that in five seconds of exposure they did not realize that Bell was an excellent violinist and not just a good one. Or that he was playing a violin worth more than that limo.

Of course they didn’t realize it. They’re not experts. And they’re not boors, either. They’re just people who don’t happen to be musicologists.

When I related this story to my wife, her first question was “why didn’t they do it at the farmers’ market?” Good question. In my town, there is a farmers market where people browse produce and, as it turns out, listen to buskers. With a receptive crowd, the musicians often make good coin and usually have a crowd around them. At our farmers’ market, Joshua probably would have made $1500 in an hour and been featured on the community cable station. In a subway station, people are rushing for trains.

Actually, I do know why they did it in the subway station. They did it there because that’s where people wouldn’t stop and listen.

The conclusion was made before the stunt was pulled. There’s a pervasive meme that seems to dominate the media nowadays. Left or right, reporters seem generally convinced that the sky is falling. Civilization is ending. We suck. We’re going the way of the Roman Empire, and we deserve it. Think of all the reporters who are politically opposite your views and you’ll see what I mean. (Take my word for it that the reporters on your side of the fence are the same.) As entrepreneurs, we have a sacred duty to not buy into that baloney. We know that in the history of the world the average person has never had it so good as they do now in the West, and that’s a direct result of entrepreneurs taking the things around them and making them better. They’re still doing that, faster than ever, and things are getting better faster than ever.

Edit: Sometimes one writes something, and then stumbles upon the article one meant to write. That’s the case here.

Funding now, funding later, funding never

When do we start to try for funding? That’s the question that’s been hampering my coding recently and making me sleep a little less soundly.

Research doesn’t help. Web 2.0 patron saint Paul says you need angel funding to succeed:

There is much empirical evidence that this is true. Very very few companies make it without the help of investors.
The wrong question to ask is “Do I need investment?”
The right question to ask is “Will taking investment help me?”
Remember that your competitors may have investment and thus a competitive advantage over you if you don’t.

37Signals, Ruby poster child and prototype Web 2.0 company, says fund yourself:

Outside money is plan B
The first priority of many startups is acquiring funding from investors. But remember, if you turn to outsiders for funding, you’ll have to answer to them too. Expectations are raised. Investors want their money back — and quickly. The sad fact is cashing in often begins to trump building a quality product.

For us the decision is dictated by fiscal reality. Two of us are working full time on our project now, and we have about 4 months of runway before banks start to wonder where the latest mortgage payment is.

But when? Pre-alpha (now), or post alpha?

Pre-alpha:

Pros: We get some cash sooner.

Cons: Technical risk isn’t mitigated yet; marketing plan is immature; market segmentation is incomplete; shape of beta is unknown; we may burn our one chance at a hearing with various angels by presenting them with an vague proposal; valuation will be much lower.

Post-alpha:

Pros: Product is in the hands of some users; technical risk is mitigated; user feedback is coming in; more known about user uptake possibilities; market research further along and marketing plan more mature; higher valuation

Cons: We may run out of money before a check arrives.

In short, post alpha is the clear winner except for the nuclear-level Con: we run out of money.

Solution: code faster.