CTO Articles
Published in IT World
March 14, 2006
How long will it take to make that piece of string?
Five words to strike fear into the heart of any software developer: "How long will it take?"
Problem 1: The questioner and the questionee often have very different skill sets. Bluntly put, they speak different languages. Getting into the details of what needs to be done is rarely productive because of a lack of shared vocabulary. "The library is not currently re-entrant therefore..." is unlikely to be a productive conversation. Same goes for "It is not that simple because..."
Problem 2: Software development is terribly non-linear if you graph progress against time. Developers know this. Managers either do not know this or pretend not to know it because time is linear, which makes the project plan linear so darn it, the work must be made linear too.
Problem 3: Nothing stands still in this business from one week to another. Upgrades to this, new versions of that. Rampant unknown and unknowable inter-dependencies... How can any well-meaning software developer factor so many unknowns into the time calculations?
I could go on but you get the idea. So, given all this, when a developer says "3 weeks" as a time estimate, what is that estimate actually based on?
The truth of the matter is that software developers - whether they know it or not - solve OR[1] problems in their heads when they give time estimates. The best calculations are based on decades of experience, the worst, on irrational optimism. Most, are somewhere in between.
I have a simple example from the early part of my own career that I think illustrates some of the issues nicely. I was working on a graphics application using a long-since-defunct Intel workstation from Sun known as the RoadRunner[2]. (I remember it had a 300 MB hard disk. You can tell we are going back a little in time here!)
The application I was working on drew bar charts in black and white. My task was to add red lines. Now, to non-computer specialists this looks like moving from 2 colors (black and white) to three colors (black, white and red). However a computer-specialist is likely to utter the five words that strike fear into the heard of any project manager "It is not that simple..."
Simply put, computers like to do things in powers of two with the odd skip. Color in a computer tends to go from 2 colors to 16 to perhaps, 64. Then comes 256 and then probably 16 thousand or so. Each of these jumps brings with it a jump in how application software needs to be constructed.
All the business application required was one extra color but providing it required a jump from a 2 color model to a 16 color model. I remember it took me 3 weeks to get the application working in 16 color mode in which I was just using three colors although I could now use Green, Blue etc. if required.
When my finished work was presented up the line, a question came back: "How long more to add Green?"
I can think of about half a dozen suitable answers to that question depending on the overall business context.
As I said, Software development is terribly non-linear if you graph progress against time.
[1] http://en.wikipedia.org/wiki/Operations_research
[2] http://sites.inka.de/pcde/collection/sun386i_250.html