Working Against the KLOC

On my very best days, I have found that I can write about a thousand lines of clean, efficient, well-documented and reasonably bug-free code. Once primed with a clear objective and having decided on methods for carrying out each of the details, it is remarkably easy to bulldoze through huge swaths of an implementation in one sitting. The challenge is to set up the circumstances that make this possible.

Before I quit my last programming job, I tallied up the amount of code I had written during my ten-month tenure. I was careful to omit vacuous lines, generated code, unit tests, inline documentation, commentary, markup and data. This was only extant code as well, as I did not count what I had overwritten in the version control system. The result was around 22,000 lines — a little over a month's worth of aforementioned best days, or a little over the equivalent of two of such days for each month I was there.

Not all of the code in my tally was part of the same project, but that which was had similar characteristics. It was a sequence of numerous attempts to articulate disparate, disconnected parts of an unprecedented, poorly-defined and ultimately elusive system. My reason for being there, and the premise upon which I understood I was hired, was to contribute to solving this novel problem. What we never did, though, despite my counsel, was attempt to clearly define it. Instead, we acted as the proverbial blind men encountering an elephant, fiercely pinching and prodding it with tweezers and toothpicks made of code. When I could no longer deny that this was the only accepted way forward, I promptly left.

Here was the tragedy. Eight months later I ran into one of my former colleagues on the street. Jokingly I asked him how the project was coming along. He said, with a sigh, that they had just completed it two weeks prior, and that the result was less than what they had hoped for. I was there for ten months, and they had been working on it for over five months before hiring me, plus the eight totals 23 — nearly two years. Extrapolating my salary over the average number of people involved, accounting for our other responsibilities and eyeballing operational overhead and capital expenditures, I estimate the project cost somewhere between 1.2 and 1.5 million Canadian dollars, all to yield a poorly-serviceable result.

I'm sure the Web is riddled with lamentations of failed, overrun or otherwise disappointing software projects, as those tend to be frequent. My intent, however, is to imagine how my 22,000 lines could have been put to more productive use, even if the only purpose of some of them would have been to glean new information about how to proceed.

The astute might remark that lines of code is an abysmal metric for programmer productivity, because it is the content of the code that is the source of value, not its quantity. This is exactly my point, because the cost to produce the code is the same or higher, whether it is put to work printing money or thrown in the garbage.

A great deal can be expressed in a thousand lines of code. For instance, an effort equivalent to the one I produced at this company, written in a modern, interpreted language, is more than ample to describe the behaviour of a typical Web-based product. In a fantastically optimistic scenario, a company's first offering could require no more investment than a few hundred hours on the part of a single person. But much like a novel, film or similar artistic performance, the fantasy lies in underestimating the effort to procure the information used as raw material, and thus how many times the projected effort is stuck, or repeated.

Once again, past the margin required to express the desired behaviour, the success of a software project is an issue of content, not quantity. Just as with any other creative endeavour, the ease with which we breeze through the implementation is directly related to how clearly we can envision the result and the path toward it. I suspect that the relative cheapness and novelty of watching software do something often distracts us from taking the necessary and most effective steps to get it to do the right thing. The half-dozen or so people in my story, including myself, ought to have been able to lick our problem in a fraction of the time and cost if we had just figured out, at the outset, what to write.