Ashley Moran just wrote an interesting article about why developers can’t estimate time.
Something most developers find hard is estimating the time something will take.
If it’s something you have done before, a repeatable task, then it’s easy – although most of the time things take longer than you think they will when you think it through in your head and quite often it turns out to be more complicated than you thought when you get into it or you hit a bug of some kind that you end up having to debug which takes a long time and compounds the issue.
Sometimes the problem of bad estimates is made worse is when estimates (which are at the end of the day an educated guess) are taken as a promise and therefore if it takes longer then there is a feeling that it should have been done quicker.
I particularly found these quotes interesting and amusing:
We can’t estimate the time for any individual task in software development because the nature of the work is creating new knowledge.
Rule of thumb: take the estimates of a developer, double it and add a bit
The double-and-add-a-bit rule is interesting. When managers do this, how often are tasks completed early? We generally pay much more attention to overruns than underruns
I listen to technical podcasts whenever I am driving alone in the car (i.e the daily commute). One of my favourites is Build & Analyze – A weekly news and discussion show about the world of iPhone, iPad, iOS, and mobile web development. Hosted by Dan Benjamin and Marco Arment (founder of Instapaper and the former cofounder of Tumblr).
This week, one of the discussion points was an interesting topic in which Marco entitled “Technical Debt”, which I found very interesting (and from experience, very true!).
The theory behind the concept of the term “Technical Debt” is this:
As a developer, every time you cut a corner, implement a hack or a short cut, or implement something in a sub-optimal way, you incur technical debt. Technical debt can be caused by time pressure, deadlines, commercial pressure or simply not knowing any better. While the feature may work fine for a while, technical debt, like financial debt has a habit of coming back to bite us later.
The re-percussions of technical debt can be things such as having to later re-write code to be able to add future improvements or tidy it up or it can be in the form of performance problems or outages – possibly brought about by a surge in popularity/traffic or increase in the amount of data in the system. You can guarantee that the effects will manifest themselves at the most inconvenient of times too.
Martin Fowler and Jeff Atwood (of Stack Overflow fame) have both written interesting posts about this concept and it’s something to bare in mind in the future when there is a temptation to cut some corners to get code finished.
EDIT: Here is another interesting article about Technical Debt.