Contact Us

Pitfalls in Software Development

This article is written by Dave Chaplin, an IT Consultant with 10 years experience. He leads and mentors teams of developers on agile .NET projects and has extensive experience in agile development techniques, particularly Test-Driven Development. Dave can be emailed at davechaplin@byte-vision.com.

Date: Sunday, June 8, 2003


We often hear that a third of all software projects deliver late and over budget. This article discusses some of the classic pitfalls that contribute to software projects failing.


The intended audience for this article is developers and project managers. In my opinion I believe that the main reasons for failing software projects have nothing to do with the technology but are more focused around project management. It is true that developers can contribute to the failures, but I also believe that if they were being managed properly then those risks could be mitigated.

So, here are what I consider to be my personal favourites!

Lack Of Risk Management

Every point I’ve made in this article represents a risk to a project. A project risk is a reason why the project could potentially fail. If you fail to manage the project risks and mitigate them early then you can bet that something will pop up and boom… failure.

Building The Wrong Thing

If you build something that is not useful for your customer the project has failed. It may well have adhered to the specification documented, but if it fails to solve the business problem the project has failed. I talk more about this in the article 'Losers Olympics '.

When the situation arises when you are building the wrong thing, the signs tend to be a large amount of finger pointing, apportioning for blame, and the obligatory ‘that’s what you asked for, this is a change request’ situations. Modern application development attempts to mitigate this risk by using iterative development to get feedback. Extreme Programming takes this to the maximum by having an On-Site customer. I’ve discussed this in more detail in Mitigating The Requirements Risk Using Agile Development .

Failure To Diagnose The Problem

This naturally combines with building the wrong thing. One of the reasons for building the wrong thing is that the wrong thing was asked to be built in the first place. One particular area this can take place is the failure to conduct sufficient business analysis (not requirements analysis) to understand what the business problems are.

If IT does not understand the business problem then they have little chance of building something to help. A typical sign of this occurring is the costly ‘lets throw something at them and see if they like it’ approach! Another common mistake is to ask the business what they want, rather than asking them what their problems are.

Lets imagine you went to the Doctor and told them what your symptoms were and they responded by asking you what you would like in order to resolve those symptoms. You say you want pills X and Y, and then you go back a week later complaining that they did not help. The Doctor then responds by stating that you asked for X and Y and then asks what you think could help next time! The point I’m trying to highlight here is the case where IT ask the business to tell them what system they should build to solve their business problems, rather than asking what their symptoms are, diagnosing the problem and offering a solution. It can also manifest itself with partially technical savvy business customers dictating the IT solution without explaining the symptoms.

I've dedicated a whole article on this topic titled Making Projects Succedd - Measurable Business Goals

Too much Focus On Technology

I once heard a spokesman from a reputable company state to an audience of IT management that unless they were starting to use XML and Web Services they would not survive. I cannot disagree more with that mentality at all. It is total rubbish in my opinion.

Technology alone will not solve your business problems. You can spend all you like on the latest whizz bang buzzword compliant (CV compliant) technology but if you fail to solve any business problems then the project has failed.

Poor Planning

Developers tend to give very optimistic estimates. There estimates tend to be based on them working flat out for 8 hours a day, every day, with no stumbling blocks, no holidays, no meetings, no bugs etc. The team leader then needs to refine those estimates to bring them in line with reality. Failure to do so means the project will be late. Going further up the chain, the project manager needs to take into account the time required for all activities related to the project to take place.

Failure to take into account every ingredient required and what the cooking times are means dinner is late, tastes foul, and the customers have left the restaurant anyway.

Right Person For The Right Job

This really fits into the poor planning section, but I wanted to pay special attention to it. Building software is hard. You need to get the right people for the right job. Asking the wrong people to do some tasks represents a risk. For example, developers aren’t great testers, and are also generally poor at interaction design. They are also not great business analysts. Business analysis tend to be pretty poor system designers as well. Plumbers aren’t great electricians, and vice versa. Accountants are great lawyers, and lawyers aren’t great accountants. Get the right people in, and get the right people doing the right jobs, otherwise they won’t be done well.


This is last because I consider it to be a very minor risk. There is some technological risk in a project, which can quickly be mitigated with prototyping early on. You can also avoid using technology that is unproven with little support. But, on the whole, project success has little to do with the technology.

Closing Comments

Manage the risks, plan well, get the right people, and don’t get hung up about the technology.

Good luck.

Dave Chaplin

Other Articles

Test Driven Development (Dec 2003)
The Losers Olympics (Sep 2003)
Making Projects Succeed: Part 1 - Measurable Business Goals (Sep 2003)
Pitfalls In Software Development (June 2003)
Extreme Web Architectures - Testing Web Applications In Seconds (June 2003)
Pair Programming and Quad Programming - From Experience (June 2003)
Making Extreme Programming A Success (April 2003)
Contractual Test Driven Development (TDD with DBC) (April 2003)
Moving To XP (Feb 2003)
Maximising Development Productivity (Dec 2002)
Writing Automated Browser Tests Using NUnit and IE (Oct 2002)
Mitigating Requirements Risk With Agile Practices (Oct 2002)
10 Tips for Successful Team Leading (Oct 2002)
Developing Automated Using Tests Using NUnit 2.0 With VB.NET (Sep 2002)
Quality By Design - Part 1.doc (May 2001)
Quality By Design - Part 2.doc (May 2001)
Quality By Design - Part 3.doc (May 2001)

Other Resources


Extreme Programming


Agile Modelling

All content © Byte-Vision Limited 1997 - 2004