I went down a six hour sinkhole last night on a project I’ve been working on for the last week or so, and that got me thinking about some realities of software development that I believe we have lost sight of. One of them is six hour sinkholes and why they happen. The problem is that we have come to believe that programming is production, when it is not. In production a six-hour failure to be productive is a horrible anomaly. It shouldn’t happen, because production is predictable and well-understood, and proceeds at a linear pace. When that pace is interrupted management is called on the carpet to explain why.
And it is a fair question. Production is quantitative. By the time you start production all the messy qualitative work has been done. Production should not, therefore, be hampered by the unforseen. Of course it often is, but then that unforseen is accounted for, the mechanisms and processes adjusted, and before too long you have a soda canning line running at 5000 cans an hour for years without stopping for anything other than maintenance. The equivalent in our business would be programmers that produce 100 lines of code an hour, every hour, except when they are out to lunch. The idea is as absurd as it sounds.
Why? Because programming is not production. It is also not a commodity, but that’s a lesson for a different time. I mention it only because once you start thinking about programming as production it’s pretty easy to think of it as a commodity. Both views are wrong. In fact, it’s pretty obvious that, as Jack Reeves has said, programming is design. It is a qualitative process that proceeds uncertainly until some level of “good enough” has been reached and the final product can be produced. And where is the production happening? Where do we have a linear and predictable process of converting raw input and specifications into a final product? In the build, of course, and that’s the whole damn problem.
In software our product is “constructed” of symbols, and the definition of those symbols and how they can be used is fully specified before one iota of our product comes into being. Therefore once we design the set of symbols we need, the production process is fast and dirt cheap. As Reeves points out, it’s essentially free. That’s the problem: programming is all design and almost no production. If you’re a manager you can say concretely how many soda cans will be filled in 12 hours, but if you venture the same prediction about a software team’s delivery of features in the same period you’ll be stepping out on a limb. They may run into a six hour sinkhole. Because they are designing, not producing.
Which is not to say that design is an unmanageable activity. Lots of companies manage it. They design to specific goals, over specific timeframes, with hard milestones. But in all of these kinds of environments there is a lot of flexibility with regard to the micro view of progress, rather than the macro. A “design team” sounds like something different than a “programming team” doesn’t it? It sounds like the kind of group you would find working to flexible schedules in a cool, intellectually stimulating environment where good ideas are prized above all else. A “programming team” brings to mind more the image of a hundred young Japanese women hunched over tables in an electronics factory soldering assemblies.
If business understood programming as design, I suspect there would be fewer projects, but better ones, and less inclination to shop coding out to the lowest global bidder. After all, it’s usually the productive piece of the pipeline that gets outsourced, not the creative piece.
