The #NoEstimates Movement is Nuts

Most software developers hate giving estimates.  Who doesn't?  But now there is a movement to ditch estimation entirely (#NoEstimates) based on a bunch of faulty logic.  They've gone too far.  Estimates serve a legitimate purpose.  Those behind this movement are an embarrasment to those of us who want to see our clients and employers succeed.  

There has always been a movement by developers to rid the world of estimates.  Now there's even a hashtag for it:  #NoEstimates.   The argument goes something like:  estimates are always wrong, are a waste of time, and are leveraged by management as pseudo-contracts that are unreasonable given ever-changing requirements.  Of course management counters by saying estimates are necessary for programmer accountability, planning, and budgeting.  Over the years sly software developer-types have come up with nebulous terms like "points" to obfuscate the estimation problem while seemingly providing management with the oversight they so desperately want.  I'll cover the goofiness of the points system, which I absolutely despise, in the next post, [[On Points]].  

Developers need to face facts:  no matter what we do some manager will always use our estimates against us.  And they'll always change requirements, usually at the last minute.  We're never going to change those facts.  Therefore WE must change OUR behaviors.  What we can't do is create ridiculous systems like "points" to avoid giving estimates.  It won't work.  And we can't spend hours and hours doing ridiculous estimating exercises (planning poker, t-shirt sizing, etc) that just waste more time and put us further behind.  WE, as developers, must change our behaviors.  

This post lists some ways to do this.  

Learn about Project Management

I am a certified PMP.  In the process of studying for that certification, as well as managing projects, I've learned how managers misunderstand DeveloperSpeak.  Example:  Dave Developer says, "I can have that feature done two weeks after the Widget Project is completed."  Manager hears, "Widget Project will be completed on March 1, therefore Dave Developer will be done with his feature on March 14."  Dave Developer should have said, "Assuming Widget Project completes on March 1, which is the current plan, it will take me 80 man hours, uninterrupted, to have my feature completed."  This is much more understandable to a manager and is clear that there are dependencies that Dave Developer has no control over.  Of course that doesn't mean your estimate will be valued, listened to, or understood...but it helps.  

Further, PM's learn about "Change Management" and "Contract Management".  Basically, we do the work in the scope document and nothing else.  Anything else must be a change request that goes through the necessary processes of sign-off, cost estimating, schedule re-baselining, etc.  However, folks try to invoke the Agile Manifesto to claim that we don't have time for change control and following a plan...we are Agile!  Yeah, sure...and that's why your estimates are always wrong and you are stressed out because you work 80 hours per week.  

In the construction industry no changes are ever allowed to deliverables without an approved change order.  The CO includes the new price and deliverable dates.  There are no exceptions.  If you want to call yourself a Software Engineer then run your projects like engineering projects.  That doesn't mean construction projects don't fail, come in over-budget, or miss deadlines.  They do.  It simply means that the failure does not lead to construction engineers saying, "let's eliminate estimates."  

Stop Misquoting "Agile" to Serve Your Own Needs

I touched on this above.  Here's another example, "we are Agile, we start coding and figure it out as we go."  Please, where does Agile say that?  Instead, agile does say, "find the most important work, the mimimum viable product, then estimate and deliver that."  Then rinse and repeat.  In PM-Speak this is called "rolling wave planning."  

There are so many examples like this of how people take a beautiful concept like Agile and twist it to fit their agendas.  

But software development is an art and art can't be estimated

I love this excuse.  The same people who spout this drivel have titles like "Senior Software Engineer."  Are you an engineer or an artist?  I'm sure the Pope asked Michelangelo for an estimate on the Sistine Chapel.  

Here's a twist on the theme, "Coding is like solving a maze, you can't estimate how long it will take to solve a maze."  

Bullshit!

You should be practicing solving mazes daily, for years, each with varying levels of complexity.  Then, when given a new maze, you can look at it, and using experiential knowledge, be able to give a time estimate to solve it.  

Here's another twist, "Coding is a craft and sometimes the unforeseen happens and therefore the estimates change."  Certainly the unforeseen does happen and if it is an EXTERNAL problem, such as a delayed server delivery or having to find a contractor because a colleague just quit, then schedules will change.  But I've seen too many cases where a developer wants to change an estimate because he wants to try out Ruby on this project, wants to migrate everything from SQL Server to Mongo midway through, write more unit tests, or refactor a bunch of working code to make it more elegant.  

Stop Worrying about Perfect Design

Software developers give estimates that assume "perfect design".  When a developer says, "that will take 6-8 weeks," the implication is "that will take 6-8 weeks to do right, following best practices of software development, with good, supportable code that has full unit test code coverage and documentation, following all ilities."  

Those are noble goals.  Everyone wants that.  

Then the change requests come in.  And managers become unreasonable.  And tempers flare.  Meanwhile, the developer still assumes all of those non-functional requirements are still needed.  He won't budge.  He will still assume that technical debt cannot be tolerated.  That's insane.  

Instead, try this.  "Sure, I can totally give you that new module and still meet our estimates and deadlines.  But you need to be aware that I can't provide you with unit tests and the code will be unsupportable a year from now.  It'll likely have a bunch of bugs that customers will complain about.  But we'll get version 1.0 shipped with that technical debt in place.  We can always go back later and fix it.  Is that acceptable?"  

If your reaction as a developer to that paragraph was, "yeah but management will never give us the time for technical debt refactoring later," then you still aren't thinking smartly.  If technical debt and unsupportable design isn't important to your manager, why is it important to you?  Why are you slavishly working for 80 hours/week to write more unit tests when it is apparently only valuable to you.   

Estimation is a scam perpetrated by managers trying to get you to work harder and longer

Nope.  Managers and entrepreneurs need estimates so that they can perform economic calculations.  If you estimate that Project A will take 5x more effort than Project B then the entrepreneur may not want to fund Project A.  There is a simple cost/benefit equation that needs your estimate to be successful.  

But let's assume all managers just want you to be a slave to your workstation, giving estimates for new functionality that they can exploit for profit.  There's a simple solution to this...when asked for your estimate, give the manager your best guess estimate, multiplied by 10.  Done.  Now you can go home and relax after your 8 hour shift, the manager still got his estimate, and he can still hold your feet to the fire to meet that estimate.  

But my manager really is clueless

So what?  Then take the initiative to train him.  I once wrote about using [[Pavlovian and Operant Conditioning]] to train managers and stupid co-workers.  Take the intiative to change your environment, don't just complain about it.  And don't teach your manager about the benefits of unit tests.  He doesn't care.  He wants estimates for a finished, saleable product.  Unit tests aren't saleable.  

Bottom Line

I could write a book on this subject it's so infuriating.  Just remember that there are economic reasons why estimates are needed.  The solution is for developers to get better at estimating, not to start some retarded #NoEstimates movement.  Developers can complain about managers and unrealistic expectations, but nothing will ever change.  Instead, developers must change.  Learn how to estimate better.  

This is just another reason why companies are outsourcing more of their dev work.  If they are going to pay for missed deadlines and estimates, why not pay a whole lot less?  Maybe instead of complaining about estimates and deadlines some smart developers will come forward that actually can meet deadlines and have a working knowledge of business.  Maybe those developers' estimates will be heard by management.  Maybe those developers will make the really big bucks.  

My next post, [[On Points]], will cover how "points" are used to obfuscate estimates by amateur developers.  

You have just read "[[The #NoEstimates Movement is Nuts]]" on davewentzel.com. If you found this useful please feel free to subscribe to the RSS feed.