Tuesday, April 2, 2013

How to Estimate Software the WRONG Way

Negotiate with the Software Developers

One of the best ways you can screw up when making an estimate is to try to negotiate the time frame with the developers. Programmers generally don't realize they are being negotiated with so this is easy pickings. They actually have no leeway in their estimates and end up telling the manager what she wants to hear.This makes matters worse because now instead of having an idea of when something is going to be done you have a make believe world based on what you want to happen instead of what will really happen. Trust me if a developer says something is going to take a week it is more likely to take longer time than it is to take less time.

Don't Cut any Features to Hit a Deadline

If you really want to muck things up stand fast on your features and put it on the shoulders of the developers to deliver what you want no matter how extravagant it is. If you don't cut features than you can safely say that your estimate is a fantasy. Features are the biggest variable in the estimation process so if you want your budget to go haywire refuse to cut anything. I would even suggest holding on to the useless features that nobody will ever use just because you want it.

Demand Results

The best thing to do is to walk in to the estimation meeting with the developers slam your fist on the table and demand results. For better effect you might consider acting like a two year old and roll on the ground kicking your legs and screaming "I want it! I want it!" Programmers with kids will get it and know you are screwing up the estimates on purpose. Maybe they will even help you with statements like "I have no clue how to do that but it sounds pretty easy. I think about an hour.".
Also consider telling the developers that "If they don't do it within your unreasonable time frame they can find a new job". That will ensure that the good developers go ahead and contact their buddies in other software firms and secure a better paying job with a better work environment. You will be left with the bad developers that the rest of the team was carrying. They are great pawns to point the blame when the project goes downhill.

Don't Prioritize

Whatever you do don't set priorities. Setting priorities may mean that the most important features are done first and the least important features will not be delivered. You probably want the opposite result so leave the developers in the dark about what takes priority. Have some fun with it and confuse them by telling them that having a window animate across the screen is more important than the database being created.

Make a Moving Target

As if software requirements don't move by themselves enough, you can help by changing things that don't need changing. Just walk in one day and tell your developer you don't like Silverlight and you want him to do it in ASP.NET instead. Here are some good ideas on what to change to muck things up good:
  • Constantly change your mind on what you think the UI should look like.  
  • Change terminology and add/remove form fields constantly. Your team will have to either update their code to change to your new lingo or they will have to live with you saying "Manager" and the code says "Team Leader". That will catch the OCD programmers and waste a-lot of their time.
  • Wait until a form is done and meets all of your requirements and then move arbitrary fields around. Decide at the last minute that you want a "search feature".
  • Large architectural changes with no added value are best. Just tell them I want to switch to MVC and  I want everything to be threaded no matter what it is. The later in the project you do this the better.

Just add More "Team Members" to Slow Down the Project

If you see more time estimated than you have in the budget just add more developers. This is a great way to screw up an estimate because naive IT managers think you are fixing a problem. In reality only so many developers can go into a project. More developers can take longer to do the same thing a smaller more cohesive team can. Also, if you have a long standing team lets say 6+ months together speeding up a new developer is going to cost you 2-6 months of turnover time that you can act like you didn't know about. 

Confuse Estimates with Goals

When a developer says he thinks something is going to take 2 weeks just act like he is not a team player. You can easily turn an estimate into a company wish list by intimidating the programmer into changing his estimate to your business goal. This should make your boss happy while you look for a new job. When the project gets canceled because you couldn't meet your budget then it's probably time to look for another project to screw up in a different company.
Combining your goals with your estimate is bound to really confuse everyone at the end of the project you can squarely point at the developers and say "They can't estimate software!" In reality you know that you made the estimate and manipulated them into agreeing. 

Do the Estimate Yourself

Programmers are just trying to confuse you with difficult to understand technical "facts". Act like you have a clue about what something will take to do based on how hard it looks to you. It takes discipline to ignore a developer when he tells you point blank that it just appears easy because you don't understand the technical difficulties. For Example:
If you want to change the background color of a button. Act like the developer doesn't know what he is talking about when he says "That will take re-creating the entire control from scratch and take at least 3 weeks." You can respond by saying something to the effect of "Don't try and confuse me with tech speak. Everyone knows you can change the background color of a button within a few minutes".
We all know that subtlety is every developers weakness so instead of just telling him you think it's easier give him blank stares and act pissed off that it will take that long. Eventually he will cave and agree to change the realistic estimate based on his prior experience and expertise into a summary of your business goals. Most of the time he is thinking of ways of getting his time back by adding more estimation time to other tasks. This works to your advantage because now it's impossible for anyone to know which tasks take longer.

Restructure the Team

Many times when a baseball team is getting smeared by another team with little chance of a comeback then both or just the loosing team will have the players switch out of the positions they are good at as a fun way of saying this game is lost but let's have some fun. The shortstop may play left field the catcher might be pitching and the pitcher could be in right field.
So because you know they will never actually hit any of the fantasy dates on paper why not shift team members into roles they are not good at. Shift the back-end developer to the front end and see if they can follow each other's work. Maybe the QA guy can start programming about boxes because it's a pretty routine task.
For an even more amusing effect forbid communication within the team and declare that they should be coding every hour that they are at work. If you see two team members "communicating" act like they are sitting in a break room wasting time like the other employees do.

Assume Programmers are Superhuman

After it has been discovered that your estimates are completely unrealistic than declare that your development team has superhuman strengths. They can:
  • Work through Holidays
  • Work weekends
  • Have no need for social interaction or Entertainment
  • Work an extra 24-72 hours in a month because you calculated every month as 31 days to make the schedule work.
  • Using only will power and a-lot of soda write 10000 lines of code in two hours to "Save the Company". Because obviously the company will go bankrupt without that window animation.
One of the positives that comes from this is that developers that were actually good will either quit or go insane either way they lose all credibility when it comes to finger pointing. You can say "It's too bad Joe went crazy. That's probably why he couldn't do something simple like change the background color of a button".
Married developers will quit because their wives won't put up with your crap anymore. Single developers will quit because they live with their Mom anyways and can just play video games until they can find a better gig.
This will leave you with the rare exception of programmers that either are loyal to you until the ship sinks or have a good sense of humor and think it's funny to watch managers walk around screaming quotes from Mythical Man month and not know it. Try shouting ".NET 4.5 is a silver bullet  or "If it takes 1 programmer a month it should take 5 programmers 1/5 of a month".

Don't Read about Estimation and Project Management

The worst thing you can do is learn how to estimate from people who have been in the industry for 20+ years and have written a book on their experiences. Act like you know what you are doing even though you have never hit a deadline. If you know who Knuth and Fredrick Brooks are then you will have a harder time screwing up estimates.
Also, please repeat the most common mistakes that programmers are taught in Software Engineering 101 and act like it's a brilliant plan. Run in the room say "We are way behind we need to hire 10 new developers right now." If you can get the exact quote out of Mythical Man month on what a bad project manager would say it would be best. Again seasoned developers will get the joke and know to move on to a real software company.


Recommended Reading

The Mythical Man-Month: Essays on Software Engineering, Anniversary Edition (2nd Edition)
Software Estimation: Demystifying the Black Art (Best Practices (Microsoft))


  1. If you don't have a *really* firm grasp on *exactly* what work needs to be done, don't rely on just one estimate. Ask a (trusted) colleague how long they think the work will take. If their estimate differs from yours by more than 20%, perhaps you missed something. Maybe there's more work that you didn't account for, or maybe there's an easier way to do the work that you didn't think of.

  2. That's a great point during a-lot of estimation meetings one developer would say a day and another developer would say a week. Sometimes this meant that the lower estimate from the first developer was because the first developer new something the other one didn't. It could be a good 3rd party tool it could be more recent experience with the problem. The one caution I would point out is that some developers are just really bad at giving an estimate and even though they may say a day its because they can't estimate and think they work a-lot faster than they do. Also it could be because there type of work is sub-par and will need more time correcting then just doing it right in the first place.

  3. This is hilarious :D

    What should I do, when I joined company and this exactly is happening in the project? :D It`s like he is going exactly though the guide :D What can I do?

  4. Its very common in the industry. The problem is caused by lack of technical leadership. It takes someone who both understands technical aspects of the project and is good at negotiating and communicating with management.
    If you are low in the organization then it is unlikely that you will be able to persuade anyone. Everyone is telling management what they want to hear and you are giving realistic estimates. You will likely be burned at the stake :)