DEV Community

Play Button Pause Button
Jayme Edwards 🍃💻
Jayme Edwards 🍃💻

Posted on • Updated on

Can We Stop Pretending Planning Software Development Can Be “Certain”?

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


🔔 Subscribe for 90+ videos on healthy software development

Top comments (11)

Collapse
 
martinhaeusler profile image
Martin Häusler

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.

Collapse
 
phlash profile image
Phil Ashby

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!)

Collapse
 
martinhaeusler profile image
Martin Häusler

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.

Collapse
 
jaymeedwards profile image
Jayme Edwards 🍃💻

Thanks Martin, I like your attitude!

Collapse
 
serhuz profile image
Sergei Munovarov

Just stop treating estimates as deadlines and you'll be fine.

Collapse
 
bousquetn profile image
Nicolas Bousquet

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.

Collapse
 
seanxe profile image
Sean Crossey

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.

Collapse
 
sqlrob profile image
Robert Myers

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)

Collapse
 
jfrankcarr profile image
Frank Carr

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.

Collapse
 
jaymeedwards profile image
Jayme Edwards 🍃💻

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

Collapse
 
asynccrazy profile image
Sumant H Natkar

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.