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 08, 2003
Abstract
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.
Introduction
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.
Technology
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
NUnit
http://www.nunit.org/
http://sourceforge.net/projects/nunit/
Extreme Programming
http://www.extremeprogramming.org/rules/testfirst.html
http://www.extremeprogramming.org/index.html
Refactoring
http://www.refactoring.com
Agile Modelling
http://www.agilemodeling.com/
|
