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

Jun 4, 2014
3 minutes

5 Ways To Do Responsive Web Design Poorly

Responsive Web Design is a website design methodology that seeks to adapt the way a website is displayed depending on the capabilities of the device that is displaying the site. Frequently Responsive Web Design is used solely to adapt to the screen resolution of various devices, but it has other applications that are yet to have full browser support, such as delivering smaller graphics automatically for low-bandwidth connections, etc. As with everything, some people do it well, while others, well, they do it poorly. Below, I show my Top 5 Ways to do Responsive Web Design Poorly.

#responsive-web-design
Read More
May 23, 2014
2 minutes

Avoid SiteCatalyst's useForcedLinkTracking and target="_blank"

All sites rely upon some third party analytics software to track at the very least the number of visitors to a site. Many sites use Google Analytics, which provide much more information that just the number of visitors. Another option that some of the bigger sites use is Adobe Analytics, aka SiteCatalyst to enable more custom tracking options that are not evident through the Google Analytics interface.

One feature of SiteCatalyst is that it allows you to set an option useForcedLinkTracking that will track every link on your site for clicks whether or not you have setup custom tracking for the links or not. Effectively what the code does is create a JavaScript event handler to intercept all click events on the <a href="http://url.com">Link</a> hyperlinks. Once they are intercepted, SiteCatalyst sends its tracking information to its servers and then procedes to attempt to make sure that the link functions properly. Unfortunately, in some versions of the SiteCatalyst code, it attempts to create a synthetic click event that works in many cases. However, if you are using Safari with the popup blocker turned on, and a target="_blank" in the hyperlink, then it will trigger the popup blocker, which simply ignores the click, and the user sees nothing happen at all. In order to fix it, hopefully the latest version of the SiteCatalyst code will handle it, turn off useForcedLinkTracking, or, as the very last resort, convert the <a /> links to another type of element and use JavaScript to open the new window manually when listening for the click event on the new element. It seems this works all the time, but it will prevent SiteCatalyst from tracking those clicks.

#javascript #rant #sitecatalyst
Read More
Jul 3, 2014
2 minutes

== and === in JavaScript and HTML Input Elements

If you read any current information about best practices in JavaScript, you will typically find the following advice somewhere in the list of things to do.

Always use === and !== while avoiding == and !=

While I will never argue against this advice, there are a few things that a developer shoule realize when using === and !== instead of == and !=.

  1. === and !== first do a check of the data type of the two objects you are comparing. JavaScript never forces you to explicitly define the datatype for an object you are creating as it will automatically assign one based on the contents of the object and how it was created.
  2. The output of all of the Math functions produce integers or floats as the datatypes for the resultant numbers. For example, Math.floor(10.39438) will produce 10.
  3. When retrieving the value of any select or input or textarea is always return as a string. This means that even though the value of the string may be a perfectly good number, it will never match a number data type. For example "10" is not equal to 10 when using the ===.

You should always use === and !== instead of == and !=, but you should make sure you understand the datatypes you are dealing with so that your comparison works as expected without any surprises at runtime.

#jquery #responsive-web-design #javascript
Read More