How long is a piece of string?
October 30, 2007 //
One of my twitters this afternoon seemed to strike a cord with the developers amongst my followers. My twitter went something like, no exactly like this
Some users may not be able to read what’s in the image above, so I’ve pasted the text below. I’ve purposely done this as Adrian (AKA Aido) is going to write a blog post about ‘creative vs usable’ and this post should act as reference.
Segala developer “not too long left”. Me “what does that mean to say, someone on Death Row? ‘how long please?” Why can’t developers ans you?
I received the following response from a number of my fellow twitters (twits?). I’m assuming they’re taking one side of the argument given that they’re developers.
Sarah Blow @PaulWalsh because writing software is a bit like drawing a picture… ask an artist how long before you’ll have your picture… the ans.
Guestimates only go so far and are always prone to the unknown… Software is a journey of discovery and the more work that.
Craig Murphy @PaulWalsh : Devs rarely commit to time constraints as the business frequently “mishear” or moves the goalposts. Further, the business often takes the first “date” a dev gives as thee date…no room for discovery, etc.
Paul Campbell @paulwalsh because of that FECKING one line that caused 2 hour long script to fall over and now means another two hour wait just to see
Even if writing software is a bit like drawing a picture, wouldn’t you have a good idea how long it’s going to take? Surely when you’re ‘almost finished’, you’d have an even better idea how long it will take to complete based on the historical data you’ve collected from the work you’ve just completed?
If you can’t estimate how long it’s going to take to complete a task, such as developing a simple site using a simple platform (what’s simple I hear you ask) how do you expect the business to appreciate your expertise.
Note that I’m not talking about guestimates of potential work. I’m talking about estimating the completing time of a current project you’re working on.
For the sake of the record, the developer to which I refer above is brilliant at what he does and is able to deliver upon a brief seamlessly. I thought my response was funny (yes I now, you shouldn’t laugh at your own jokes) and decided to twitter it.
What do you think?
—
If you’re already on Twitter then feel free to follow my stream of nonsense. If you’re not already using Twitter, don’t bother trying to make sense of it until you’ve used it for a while and managed to build/join a small community.
offbeatmammal says 
Chris says 
oliver says 
Les Hoskins says 
Such a personal issue — I’ve been working on the set of scripts I tweeted about above for two weeks. Almost every day I say to myself “I’m going to finish this today” — but tiny things keep creeping in to hinder the development. It’s impossible for me to predict the time that the one line that I accidently left in when I was adding a piece of functionality will hold the development up — not to mention the time taken to find the issue and to check if any similar little accidents creep in.
Regarding “developing a simple site using a simple platform” — I’m taking one look at that and running. You put it best yourself — ’simple’ is different to so many people.
Looking at the time it takes Google, Apple etc. to develop their ’simple’ sites is a good exercise. I don’t know how the development schedules in there work, but I expect that the consensus would be that quality takes time and that it’s always worth taking the time to get to that quality, or at least some balanced function of that.
October 30th, 2007
Paul, could your error been avoided by testing more often? So, rather than continue to develop, you would test periodically so that any errors found would be more easily identifiable? It’s more a question about process of defect management than development however…
October 30th, 2007
Paul,
I was testing as I went — but on a much reduced dataset — the little accidents didn’t appear until I introduced the to the huge datasets. That said, a lot of the delay on this particular one probably could have been avoided had I a bit more experience, but still, I think the point holds — there are three stages in solving a development problem — the on paper solution, which can often take quite some time. Then there’s deciding how to implement that solution — usually the quickest part.
I think it’s the part that lulls one into a false sense of security — inevitably problems arise in the implementation stage that simply didn’t come up on paper, or deciding on how to tackle the on paper solution. When they do arise, it’s often the case that they need to be treated as separate problems, but as time etc. has already been agreed and other pressures arise, the old cowboy rears his head, and before you know it, the shit is stirring and mayhem / delays ensue.
But to reiterate — it’s often the discrepancy between specs and implentation that cause the most delays — hence (I assume) the shift toward agile practices and quick release cycles — taking small chunks at a time and piecing together an application by degrees, or inches … with more of an emphsis on user-centric features getting rolled out bit by bit, rather than hitting strict release cycle deadlines to the detriment of the software itself.
October 30th, 2007
Joel Spolsky has an interesting post on Evidence Based Scheduling which addresses the question, “how long will it take to build Project X?”.
Incidentally, Joel’s in Dublin next week.
October 31st, 2007
I hear you Paul. My background includes business process improvement for software delivery - I know only too well that each stake holder is responsible for holding up a project at some point. In most cases, it’s unfortunately the fault of the project manager not managing this obvious fact and helping each of them to understand the importance of their output.
It should be possible - it is possible, to estimate how long it should take to build something, even if that estimate isn’t entirely accurate. I won’t go into each method as it’s a post of its own I guess.
Lar - thanks for the tip. Nice title as its sums up part of what I’ve said; historical data…
October 31st, 2007
Paul — agree 100% … it’s the responsibility of all involved to use their experience to give an honest estimate — but also to take the responsibility to understand that it’s just that: an estimate.
October 31st, 2007