Should We Give Up Trying to Estimate How Long It Takes to Write Software?

This is a fascinating interview with David Heinemeier Hansson, of recent fame. He makes the point that when building software, we shouldn’t try to estimate features and then fit them into two week sprints. Instead, it should be possible to determine the value of solving a particular problem and then set time boundaries on solving it. The timeframes needn’t be short two-week sprints as if often the case in scrum, but something more suited to solving the problem in hand, say 6 weeks.

His central theme is that software is more akin to creative projects like books or movies than big engineering projects like building a skyscraper. While I think there are some interesting ideas here, and as a practitioner of Scrum I am also keenly aware of how easy it can be to become dogmatic about the various ceremonies and systems it advocates so much so that you end up becoming less agile.

That said I think shorter iterations are useful when you are unsure of the value of a certain feature. Building the smallest MVP allows you to test the market in order to determine the value. The idea of setting a time budget and giving the team a couple of months to build out a feature without the overhead and bureaucracy that Scrum entails does seem incising however, and may be appropriate in some cases. I will try to keep this in mind as I develop projects in the future.

Leave a Reply

Fill in your details below or click an icon to log in: Logo

You are commenting using your account. Log Out /  Change )

Twitter picture

You are commenting using your Twitter account. Log Out /  Change )

Facebook photo

You are commenting using your Facebook account. Log Out /  Change )

Connecting to %s