I recently acquired a Wells-Index 700 CNC mill, and it arrived at Site3 in October. It was sitting in a shop in Edmonton where it was intended for a project that never materialized. Before that it was hard at work making chocolate molds for the Mars candy company. Thanks to the folks at Wells Index for keeping such good track of their machines.

Shipping the machine was a bit of an adventure, since it measured about 8″ higher than a standard city truck.  On the shipping end they had to send the first pickup back and bring a semi in to load it.  On the receiving end (Toronto) the shipping company declared that they couldn’t get it to Site3 because it wouldn’t fit on any of their trucks – we would have to pay for the rental of a flatbed.  My friend Christopher, who has much more experience with shippers than I do, got on the phone and managed to persuade them to drive the rig it was already on into downtown Toronto.  I learned two things: swearing at shipping managers is an effective negotiation tactic, and never mess with Christopher.

Christopher also drove the forklift we rented to get it into the shop.  It is an extremely top-heavy machine, and wobbled alarmingly.  He got it off though, and down a really bumpy alleyway, and into the shop.  He was so skilled that I doubt more than five years was taken off my lifespan.

Unloading the CNC mill from the truck

Unloading the CNC mill from the truck

Getting the mill into the shop was a challenge too. We had to remove the motor so it would fit through the doors, and saw off the ends of the oak pallet. That gave us about 2″ of clearance in both the width and height. Christopher managed to get it through the doors after about an hour of shuffling the forklift back and forth inches at a time.

Sawing off the pallet

Into the shop it goes

Getting the mill off the pallet was another hair-raising job, as it weighs about 3500 lbs. We rigged up a beam over the mill and chained the mill to it, then jacked up one post to just lift the mill off the pallet. We slid the pallet to the front of the mill, blocked the back with a 4×4, and lowered the mill. Then we lifted only the front, slid out the pallet and lowered the front onto two 2x4s stacked flat. Then the back was lowered onto a 2×4 plus a 1×4 stacked. And so on, until it was on the floor.

Today, Seth Godin asks about making it up as you go along:  is there any other way? That sounds like a tautology, but it’s not.

First, an apology for Making It Up.

A few months ago I was talking to my uncle about a business meeting I was in.  I described how I was caught flat-footed by a question and invented a new feature for our product in order to answer the question.  My point was that my CTO was going to be pissed at me, but somehow he took a different message.

“You spend your days making this crap up,” he said.  It wasn’t a statement of admiration.  I slinked off to talk to my aunt about gardening.

‘Making it up’ has a perjorative air to it, although I’m sure Seth doesn’t think it’s a bad thing.  To many ears, though, it’s the opposite of expertise.  If you make it up, it’s because you’re lost: you don’t know what to do, you don’t have a plan, you’re a pretender.

Entrepreneurs and makers know that the ability to make it up is a joyful thing, of course. Steve Blank is the poster boy for b.s’ing your way into entrepreneurial success, and his analysis applies to makers too: makers and starters deal with unknown solutions, and often with unknown problems. Making it up as you go along is inevitable, unavoidable, and ultimately, desirable.

So to give it respectibility, I’ll start calling it ‘improvisation’.

In coding, we encounter improvisation constantly.  We improvise when we debug.  We improvise when we solve detailed design problems on the fly.  We improvise when we encounter missing library features or changing requirements or an O(n^2) routine in a standard library class.  Agile methods are built on improvisation: at its best, pair programming can be like a jazz duo completely familiar with each other, riffing off one another to create something impossible with one instrument.

Entrepreneurship is impossible without improvisation.  That is a tautology to anyone who has started a company.  Not only is the solution to the problem you’re tackling unknown, but as Steve Blank argues over and over again, the very problem itself is unknown.  Any entrepreneur will constantly find herself in unfamiliar situations, muddling along, generally shattering or at least damaging the rules of how things are supposed to be done. Really successful entrepreneurs redefine those rules: then we call them innovators.

But still, there’s a reason my uncle isn’t impressed.  The suspicion people have of improvisation is well founded: everybody has experience with pure bullshit artists who are all codpiece and no, um, cod.  So what’s the difference?

It’s worthwhile to analyze improvisation to separate effective, essential improvisational thinking from destructive guesswork.  I’ll take my best guess at the difference next.

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.

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.

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.

In his blog How to Change the World, Guy Kawasaki regularly slips in an article about hockey. Those articles are typically the lowest rated and have the fewest comments of any of his excellent articles.

What is a Canadian entrepreneur to think? I suppose it is understandable, given that for some inexplicable reason the founders of the digital revolution chose surf and babes over pucks and parkas. But ignorance is only an excuse until you have the opportunity to be educated, and so I give you:

The Top Five Reasons Hockey is the Entrepreneur’s Sport

5. There are a pile of ways to be a successful hockey player. You can be small, fast and agile; you can be strong and determined; you can be good with your hands; you can have a powerful slapshot; you can be deceptive; you can have the world’s best balance. You don’t need them all. Likewise the entrepreneur does not need to satisfy some master checklist of qualities. She can find a way to leverage her strengths to succeed.

4. Hitting is allowed, and encouraged. The game is real: if you allow your attention to wander you will be knocked off the puck. No reality distortion field protects you from that harsh fact. What rules exist are there to prevent serious injury, not give you a glass bubble to wander around in. Coming from school or an internal corporate project to an entrepreneurial endeavor feels like shifting from a ballet class to an NHL rink.

3. Speed and agility are key. Not everyone on the ice knows where the puck is all the time, but you better believe at least two of your opponents do. Always. And they are skating for it as fast as they can. If you cannot beat them you will lose. If you do beat them to the puck, you will have between 1 and 3 seconds before your opponent is there trying to take it away from you. You therefore have an average of 2 seconds to move the puck someplace where he cannot remove it from you, and dance out of his way so that he cannot remove you from the puck instead.

2. Hockey is played by the players. The game happens so fast, and there is so much information flowing on the ice, that there is no way a coach can even begin to puppeteer his team. The coach’s role is to prepare the team during practice and maybe pull players if they’re not up to snuff, but if a coach calls a timeout it’s really just to let his squad rest. They have to play the game, all of it. Books and mentors and investors and seminars and support groups can help prepare the entrepreneur, but once the game starts, their help is over.

And the number one reason Hockey is the King of Entrepreneurial Games…

1. Hockey is a game of time and space. Good hockey players are like chess players at warp speed. They see the rink as it is now, and they visualize it as it will be in five seconds. They see the spaces and they know how they will be filled. When a player is in the right spot to receive a bounce and go in on a breakaway, they were not lucky: they saw the pass, they saw the bounce and its angle, and they moved to get there — before the pass happened. They’re wrong… a lot. But when they’re right, it’s magnificent.

So go rent Slapshot, buy some videos of the Oilers in the 80’s, then go start your company.

And remember, keep your stick on the ice.

Yesterday, I had a meeting with the president of the company that I work for (it’s a small company) and the managing director. I quit. Nicely, of course, but I quit. I’m launching a startup.

(Yes, I know — who isn’t?)

Part of my preparation has been reading everything ever written, and several things that weren’t, about entrepreneurship and what it takes to start a company. Here are some of the things I’ve learned:

  • You have to be young – less than 28 is best
  • You have to be single
  • You have to be older: two or more prior startups is best
  • You have to have a PhD
  • You have to live in the Valley
  • You should drop out of school
  • You need a professional manager with a business degree
  • You’ll sink if you have an MBA on board
  • You should all be coder rock stars
  • You should have a diverse set of skills on board

etc., etc. My conclusion is, of course, that it’s all stuff and nonsense.

Here’s why: survivorship bias.

Suppose you’re a financial analyst, and your Grandma wants to retire from the textile factory. You’re going to invest her money for her, and since she’s family, you decide to actually do some math to see which portfolio is better: one made up of growth stocks or value stocks. (Never mind how you tell one from another — that’s a fairy tale for a different day.) You dial up your Internet connection, log into AOL and tabulate the results of the top 100 value stocks, and the top 100 growth stocks over the last 10 — wait, it’s Grandma — last 25 years. You conclude that you should put your money into…

It doesn’t matter. You’re wrong. You’re wrong because you’ve fallen victim to survivorship bias. Your sample of 200 stocks only included those that survived — the companies that went belly-up were not included in your study. If you did that study today, your list of stocks wouldn’t include Enron, WorldCom, or a host of other “solid” companies that went quietly into that good night. To eliminate the bias you would have to examine what stocks were available at the time, and track those through 25 years, including the occasional bankruptcy in your calculations.

If you think such an error is juvenile and obvious, think again — it’s made time and time again in the popular and academic press. It’s made by academics and political pundits and sports commentators and bloggers. It’s not a quaint, old-fashioned mistake: its all over the New York Times today and it will be all over the Wall Street Journal tomorrow. It’s the first thing to check for when your B.S. spidey-sense is tingling but you don’t know why.

Survivorship bias is especially prevalent when people analyze companies or people. Books that profile successful firms or individuals and draw conclusions about what qualities contributed to their success ignore the possibility that there are many firms or people with exactly those qualities that did not succeed, or did succeed but not as brilliantly. So books like Built to Last and Secrets of the Millionaire Mind are entertaining to read, but not particularly illuminating. After all, there are tens of thousands of hardworking, frugal people who pay close attention to the bottom line but do not get rich.

So we come to theories about what it takes to successfully launch a startup. Folks who say, for example, that you’re really better off being under 30 and single to launch a tech startup probably feel like they have good data: they look around and see that most hot new Web 2.0 companies seem to be headed by young men. (And it is, sadly, mostly men.) They may even do some counting and put some numbers to the claim. But to prove the point, one would have to look at 1000 or so startups as they began, and see if having a young founder improved the odds of success.

Say for example that out of 20 successful startups, 15 have founders under 25. That alone proves nothing; if 1000 startups were launched to produce those 20 success stories and 750 of them had founders under 25, then age would have zero influence on success rates. If only 200 of the 1000 had founders under 25, though, you’d really be onto something. One could do a similar experiment with claims about geographic location: I suspect (but don’t know) that many more startups are launched in the Bay area or one of the other startup hubs like Boston or Seattle than in other cities. It would not be surprising that so many more successes came from there. To determine if geography was a factor in success, though, one would actually have to do some serious counting and tracking. Statistics on the table, as Stephen Stigler says.

The position I’ve been arguing against is admittedly a straw-man: nobody actually claims that you cannot start a tech company if you’ve seen 30 Christmases. There are, however, plenty of people saying you’re bucking the odds if you don’t pass this or that filter. But there are enough factors conspiring to discourage would-be entrepreneurs from launching their ideas without adding spurious ones to the mix. So my advice is: when you read something that suggests that qualities you have are required for success, believe the writer wholeheartedly – you’re going to need all the optimism you can get. But when you read that you lack some necessary ingredient for success, check whether the writer has done any counting. Then go start your company.