If you've developed software for even a few years, you know estimates are basically worthless.
Unless you're estimating old technology, and building something trivial - the company's asking you to commit to something you've never done before.
I've heard the statement before that being an "agile" team or company is only possible if it's accepted from the leadership all the way down to the individual developers in a company.
The hardest part about being agile is that we still find out we're wrong, and even more frequently!
The question is: how do people treat each other when they're wrong?
Click below for the full interview with Scott Nimrod.
📺 Watch the full hour on YouTube
Or listen as a podcast:
🎧 Soundcloud
Top comments (11)
It's not just about estimating. I wish people would recognize that software development in its entirety doesn't fit into the "industrial mass production scheme". We pretend that it's plannable, even put estimates on it. A single unforseen issue may require a rewrite or redesign and cost you weeks or months. It is not possible to put a handle on software development in the same way as when building the 100th instance of the same car. It just doesn't work.
Well put, and the driving force behind a number of other software engineering practices that attempt to limit some of the really big impacts of change, practices such as decoupling, evolutionary design and microservice architectures (rapidly turning into a new philosophy that reaches way beyond technical sphere - officially a good thing IMO!)
Yes, thank goodness we have architectural patterns and other things to keep programmers sane. However, it's never a guarantee that things will get done in time. There is always an unknown element to software development, otherwise an existing solution would be used instead of developing something new.
Thanks Martin, I like your attitude!
Just stop treating estimates as deadlines and you'll be fine.
Exactly. I remember that in FogBuzz for example (JIRA/Bugzilla alternative), they method to size is to ask people to divide work in small tasks of a few day as much and to provide who did the sizing.
When the work is done, people have to put in the actual time spent on the task. Once you used the system for some time, it has a database on size for most people and the actual spent associated to it.
So when you size new projects containing many sub tasks the system is able to provide you with a gaussian curve of probability to be finished by that time. This seems more reasonable.
Yeah, this is the only answer needed really.
Estimate your work, double it, tell management as a guideline that when you'd like to be finished.
After 2 weeks (or however long your sprint is) estimate again.
Couple this with daily stand ups and estimations are fine.
The old joke estimate, which seems to come out accurate more often than it should is to double the it, then up the units by one (e.g 2 days => 4 weeks)
Estimates serve the important purpose of giving management the comfortable fiction that the metrics the hold so dear reflect reality. That's why you should practice the Montgomery Scott rule, always double the estimates you give the captain (aka management) so that you can have a reputation as a miracle worker.
I wish this always worked! Unfortunately I’ve seen tasks take 6x original estimate and at unhealthy companies, developers can be forced to burn themselves out rather than leadership resetting expectations.
YMMV
By Murphy’s law you are always going to miss your deadlines, so best thing is take your time and think and write piece of code, instead of doing crappy job.