Last weekend, I participated in and helped organize the CodeChef TechTalks. In Bangalore, we had a birds of a feather session where the question was asked, why do we need estimates when developing software? Here’s my take:
- No one is good at estimating - I’ve never met anyone who can consistently, correctly identify how long a development task will take. In the case that you do manage to complete a task within your estimate, it’s most likely you’ve added a 50% buffer (i.e. which in essence is saying you have no idea how long it’ll take)
- Estimates cause stress - The developer tells the project/account/product manager that a feature will be done in 3 days. The manager tells the client it will be done in 6 days (they of course add another 50% padding). 6 days later the feature is buggy, doesn’t work in IE and is no way client ready. Everyone is angry and pointing fingers.
- Estimating takes time - It might take half a day to figure out all the nuances of a particular feature and account for everything that may go wrong before an estimate can be given. This time is better spent developing working software.
- Estimates reduce the quality of software - “I gotta get this feature out the door tomorrow, there’s no way I’m writing tests that will help me update and maintain the system down the road. I’m hacking this together so I can watch football on Sunday.”
If you ask most managers, the reason they want estimates is to: make sure projects are on-time, measure return on their investment, see if they require additional/fewer developers, help prioritize new features, and to help plan with other teams.
I don’t really buy it though. It seems like all the reasons above can be accomplished without estimates. Instead, the focus should be on “are we consistently delivering value through short incremental releases at a sustainable pace?”
When we talked about this as a group (almost everyone was a developer), they said this all sounds great, but how do we convince our company to scrap estimates? We didn’t really come to any consensus but some interesting suggestions included:
- Release code to production often - Instead of working on a feature for a month, then at the end of the release finding out the a client requirement changed, or that the implementation wasn’t as per their expectation, release code often and get feedback quickly.
- Deliver software in thin, vertical slices - In most typical construction projects you work on the foundation, then put in steel beams, then put up some walls, insert windows, put in carpeting, etc… Once the entire building is mostly ready, can people start moving in (I have no idea if this is actually how buildings are built, you get my point though). In Bombay I’ve seen some constructions projects in which they will finish a section of the building completely, before they start on the next floor/wing/etc… People can start living there (deriving value), as soon as that piece is done.
- Focus on customer happiness not features - If you get your clients/customers involved, are transparent about your process, get feedback early and often and demonstrate constant progress, everyone should be happy, right?
One of the joys of working at a products company is that we don’t have clients making ridiculous demands (like asking us when stuff will be done 
). Certainly in a service company it’s a lot harder to pull this off. Instead of drafting a proposal for a certain set of features delivered at a fix price in a fixed time period, maybe moving to a monthly retainer is better for both parties (though this definitely requires a high level of trust and maturity).
If the post above doesn’t convince you, my buddy Naresh wrote a better post (with some very interesting comments) here. What do you think, are estimates a necessary evil?
No related posts.