Estimating Software Development Projects is Hard

As a software developer, working with non-technical management and end users to define a deadline for when a project will be ready to use or how long it will take from start to end of a project is an extremely complex task. Unfortunately, the non-technical audience thinks that it should be simple to give some sort of estimation on the fly without detailed analysis of the project and what it involves, as it seems simple for them to estimate tasks that are like ones they have done before.

Unfortunately, a good software developer will do anything possible to avoid having to repeatedly do the same task. They will instead automate the repetition of the task so that it will automatically happen when needed. When tasked with estimating a new project, the standard practice for a civil engineer building a bridge or a homebuilder building a home is to break the major task into the largest possible tasks that can be estimated to the precision necessary to the project. Many times, these tasks have been completed previously, with the amount of time and effort to complete being well known.

When compared with the projects that software developers face, however, it is quite a different story. Anything that a developer has done before, they should be able to reuse in the new project, making the time to implement known functionality almost 0. Once you start looking at the remaining functionality, there are a great number of unknowns that must be accounted for, assuming you have a good understanding of the problem that the project will be solving. However, I have seen that many times, the initial problem definition for the project will be lacking details, resulting in a project that lacks functionality that is required by the customer. As a result, partway through the development of the project, the missing functionality is discovered, added to the project definition, frequently without updating deadlines or time estimates.

Any time you have someone estimate how long it will take them to complete a task they have never completed previously, the estimate will vary widely from the actual time needed to complete the task. This is precisely what we ask developers to do when we want them to estimate the time it would take to complete a software development project within a reasonable 10% margin of error. The best that the developer can do is get a rough comparison to a similar project they had worked on before, but really has some fundamentally different requirements, making it too dissimilar to be an accurate estimation aid.

In the end, if management decides to judge software developers on the accuracy of their development estimates, they are judging the wrong output of the development team. Instead, they should be judging the business value delivered when a project is completed compared to the cost required to deliver the value, and how accurately and defect-free the end result is.

Tags:

Related Posts

May 12, 2014
2 minutes

Mobile Web Development Is the New Internet Explorer 6

Developing a website that works well across devices and browsers is an excersize in playing Whack-A-Mole. Once you get one browser working on a desktop browser, you go to the next browser and find that not everything works the same way. In 2014, it seems that there aren’t that many differences in functionality between desktop browsers, but that all changes once you start making a responsive website that must handle mobile devices as well as it does desktop browsers.

#internet-explorer #responsive-web-design #rant
Read More
Jun 12, 2014
One minute

Code Style Guides - Consistency is King

There have been countless flame wars online about the details of the guidelines that appear in various Code Style Guides. Some of the most famous are the tabs versus spaces arguments, whether or not to put curly brackets {} each on their own line, whether you should even use the curly brackets {} for one line actions in if statements.

I am here to say that the only thing that matters in the style of your source code, other than syntactically correct code, is consistency. When a codebase has internal consistency, developers new to it are more easily able to pick up the meaning of the source code contained within instead of having to first understand why the different styles in different sections matter, or not.

#rant #design-patterns
Read More
Apr 16, 2014
2 minutes

Top 5 Ways to Make a Developer Your Enemy

Developers are known to be some of the most finicky employees you will encounter in the workplace. However, this is a list of things that will annoy or infuriate developers and non-developers alike.

  1. Have the IT Manager send an email to all staff saying that all computers will have a keylogger installed. – This one is wrong on so many levels, the least of which is that it shows how little faith the company has in its employees and breeds mistrust of authority.
  2. As a Manager or Team Lead, take ideas and suggestions from meetings with your team, and pass them off to upper management as your own. – This just reeks of someone that is only in it to gain more and more power.
  3. As a Manager, don’t take the heat when things go wrong and blame the lowest-level employee instead. – I’ve seen senior management that is supposed to keep track of projects, ignore the project, and when it is the due date, blame those doing actual work on the project, throwing them under the bus.
  4. As a new employee, on your second day of work, tell anyone that will listen or is within earshot that you are able to rewrite the entire codebase in three short months. Bear in mind, this codebase is over 7 years old and has a team of more than 20 developers working on it, but of course the newbie can rewrite the entire thing in no time flat.
  5. As Management, when a developer hands in his/her resignation, schedule a meeting to try to first place a guilt trip on said employee to convince them to stay. If that doesn’t seem to work, then threaten to give the employee negative referrals if they don’t rescind the resignation and continue working for the company. Keep in mind that this occurred in a right to work state, meaning that there is no agreement in place that the employer would not wait a day or week or month and fire the employee without cause, just out of spite for wanting to work elsewhere.

These are just some of the things that will anger a software developer, so, be aware to avoid these if it matters at all to you.

#rant
Read More