The amazing adventures of Doug Hughes

As Thomas Pender states in his book, UML Weekend Crash Course, software development is not a formal discipline. What this means is that application programming, unlike, for example, bridge building, does not have formal standardized processes.

Consider this comparison: Bridge builders (as well as other engineering and construction professions) are renowned for designing and building highly reliable structures on time and on budget. Software developers are notorious for building highly unreliable systems which are delivered late, if ever, and over budget.

When was the last time you drove over a bridge which collapsed? How about the last time you had a problem with software?

So the question then becomes why do so many software projects fail? Well, there are many facets to this question. However, I personally believe that most of the time the failures result from a failure to manage and control common problems in software development. These problems include, but are not limited to:

Problems which are managerial in nature:

  • Project Requirements are Poorly Defined

    How many of us have worked on projects where there were no documented requirements? I have sad memories where the only requirements for projects were notes I scribbled down while talking to clients. Most of these projects failed to get off the ground.

  • Lack of User Feedback

    Lack of user feedback is a serious problem in software development. In many cases, projects I worked on failed due to a lack of user feedback. There were many times I was left without any feedback on what I was building until the first version of the software was completed!

  • Change

    As software development progresses there are bound to be changes. These changes can be a result of changing client requirements, lessons learned in previous development cycles, or for any other host of reasons. Failure to control change can lead to scope creep and projects which are never complete.

  • Unrealism

    We’ve all worked on projects with unrealistic requirements. These might be unrealistic expectations or unrealistic timelines. If a project has unrealistic objectives, how can you ever hope to achieve them?

Problems which are not necessarily managerial in nature:

  • Complexity

    Let’s face it, software is complex. I challenge you to name one piece of machinery which can produce as many outputs as a simple text editor. Unfortunately, over time, even with the best intentions, complex software applications tend to break down into buggy, difficult to maintain spaghetti code. Complexity is a big threat to the successful completion of an application.

From the perspective of a software developer this list of problems can seem quite daunting, to say the least. But take heart! Bridge building was not always a science; it has matured over 3000 years. Bridges have not always been built on time or on budget. Sometimes they fell down! I interpret this to mean that software development will continue to trend towards more reliable systems developed increasingly on time and on budget.

For many years now people (who are much smarter than me) have been working to formalize the software development field. The results of their work are concepts such as UML, various Development Methodologies, Design Patterns and much more. As developers, we are beginning to be responsible for not only keeping current with the most recent technologies, but also the most recent techniques. These techniques can help manage the problems listed above and help us to deliver reliable software on time and on budget.

Development Methodologies

Development methodologies are a means and technique applied to the entire process of software development, from inception, though requirements gathering, programming, project completion and everything in between. Development methodologies do not necessarily directly impact the code created. They do, however, define the process, vocabulary, rules and guidelines for creating software.

In a nutshell, development methodologies are a science of the process of creating software applications. There are literally hundreds of formal development methodologies. This might be because not all methodologies are well suited for types of software or all development teams.

A methodology which is iterative or incremental in nature will help in defining project requirements and obtaining user feedback. It will also help integrate change into the development process and foster realistic expectations.

Object Oriented Programming

A greatly simplified definition of Object Oriented Programming (OOP) is a programming technique in which code is grouped into objects which make up a software application. Objects abstract and provide ways of manipulating data. I will not get into the details of Object Oriented Programming. There are many fantastic resources on the web dedicated to Object Oriented Programming.

Object Oriented Programming helps you to create more manageable software applications by helping you to control the interrelated problems of complexity and change. Because program logic is encapsulated into logical objects, Object Oriented Programming helps control the complexity of software code by helping to prevent redundant and spaghetti code. By controlling the complexity of software changes to the software become easier. Object Oriented Programming also helps to reduce the cost of maintenance and helps in the creation of reusable code.

Uniform Modeling Language

Unified Modeling Language (UML) is a standard way of modeling and describing object oriented software systems. UML provides a visual vocabulary made up of icons used to describe object oriented software systems. UML does not define how the diagrams are to be used and allows architects to apply their own styles.

Because UML visually describes complex systems, it is a terrific tool to use so that all stake holders in an application can understand it before any code is written. UML helps expose potential problems, limitations, misunderstandings, and more in a complex system before the system exists.

UML is compromised of a number of diagrams, each with their specific purposes. Notable among these is the Use Case diagram which visually describes interactions between the system and users. This diagram illustrates to both clients and developers how a system will be used. This information is useful for validating requirements, helping clients provide feedback, and facilitates change when it’s most easily integrated.

UML provides a comprehensive way to understand complex systems. Because such an understanding is available before the system is created, it makes it easier to comprehend what will be required to build the system. Therefore, UML helps to foster realistic expectations of delivery timeline, system features and more.

Design Patterns

Design Patterns can be defined as time tested solutions to recurring software design problems. The concept of Design Patterns comes from the construction and engineering fields. Engineers came to the realization that for a particular class of problem there was frequently an eloquent solution could be applied time and time again. The same principal holds true for software development. By applying Design Patterns to software development problems you can help improve understanding and comprehension of a complex system across the development team. Design Patterns also help to create more reusable and flexible code.

As you can see, there are many techniques which can be applied to the software development process to help insure project success. Over the next few weeks and months I hope to touch on more of these issues. In particular, I plan on a high level review of Development Methodologies, requirements gathering, and lots of details on the various UML diagrams. If there is anything in particular you would like to see covered please leave a comment.

Comments on: "Why So Many Software Projects Fail and What You Can Do About It" (5)

  1. Practical and/or real-world applications of UML in sample/real projects.


  2. Doug Hughes said:

    That’s the plan. You might want to check out this article.


  3. Chris Ashe said:

    Is there any further progress on this? I have a team that needs to get up to speed on OO and UML as it relates to CF.

    Warm regards,



  4. Doug Hughes said:

    Chris – To be honest, things have taken a bit of a turn for me. I’ve become quite busy and taken up working on an open source project. It’s still a big interest of mine though.

    If this was a failure, I think I’d file it under “Unrealism”. 😉


  5. Vijay Kumar said:

    I believe that timely un-availablity of reusable code and libraries is one of the major thing that contributes to a project failure. This is caused because the requirements are not understood propoerly, and also the staff collecting the requirements does not have adequate knowledge and strength and lacks experience.


Comments are closed.

Tag Cloud

%d bloggers like this: