Software has a personality that attracts the classical love-hate relationship. We love the efficiency and convenience of software, excitement of creating a new software, anticipation of exploring and using a new software. Yet we hate the complexity in the development, management and maintenance of software. Software is known for running over schedule, over budget, over buggy, overly slow. Those who have experienced the development of major software project understand this delimma. So is it possible to increase the love facter and lower the hate factor in software development? Well, let us look at the main causes of a software development failure.
Developing a software is similar to building an integrated resort on an open piece of land; the outcome of the software is restricted only by our imagination. There is no rules to say the screen need to be rectangle, or how to save and present data, or how flexible it has to be, etc. There is not limit to the options and choices. In addition, there are many phases to a software development, as there are many different people with different interest in the projects. On top of that, there is always hidden users requirements that will be left hidden until parallel testing, and there is always a need for many change requests after the system have gone live. If that is not complicated enough, any wrong decision made at any one stage or action or no action taken by certain group will have multiplication effect on the subsequent stages of the project.
So how do we deal with them. Fortunately, software have matured through the years, and have numerous practices that are support to address most of the above mentioned issues. However, today we are still encounter and even higher degree of the above mentioned problems. So this blog we will list out some of the common causes of software project failure, identify their root causes and how to prevent them...enjoy!
SIN #1: BAD ARCHITECTURE
The internal of a software system is like a human body. For example there is functions(organ) to handle receiving information from user(eyes, ears, nose, tongue, etc), process that piece of information(mind) and save permenantly in a database (mind). Software architecture controls how every part of a software should communicate with one another, how they should process information and how they should present those information. Any new or changes to an existing software will have to be developed on top of the architecture. So if the software architecture is not well design or development, this flaw will be pass on to all software that develop on it.
When we have a well design and developed software architecture, complexity in developing a software will be substantialy reduced. Imagine if we have a flexible, robust and efficient artchitecture that handles:
* Creating an entry form that allow user to create, edit, view, delete
* List the data with filtering options, and multiple selection options
* Creating complicated reports
* Audit
* Data Processing
With a clear programmers' guide, a software can be developed with minimum hustle.
However, because of complicated user requirements and demand to have the software completed at a minimum budget and at a shortest timeframe, many companies are not able to achieve the desired outcome in their software project. To build a flexible, robust and efficient architecture requires time, and usually do not reap immediate reward. The rewards comes when it is being used to build more software or when handling change requests. But because of the pressure from every angle, we take shortcut in the area. Hence we commit SIN #1.
SIN #2: INCOMPLETE ARCHITECTURE AND FRAMEWORK
If Software Architechs stopped improving the architecure and framework after some time. However, this is inviting duplicated coding (sin #3). Because it is incomplete, programmers may be able to find an architecture suitable for certain design. As Architechs do not have the resources to make the enhancements or changes, they often recommend workaround to solve the problem. As this workaround are not part of the architecture, it become a one-off thing. So when another programmers need the same thing, will again develop their own code to handle the workaround.
So it is critical that Software Architechs are given ample resources and they should also expect to handle any changes or enhancement to the architecture and framework for every new projects or change requests.
SIN #3: DUPLICATE CODING
If we have the best Software Architecture, and Framework, but programmers do not know about it, it will still be of no use. When programmers are not aware of the Architecture and Framework, they will usually develop their own. Beside being duplicate work, it will become maintenance nightmare when left unchecked. But this is very oftern the case. Hence, our SIN #3.
So there should be a clear and up-to-date programmers' guide and training provided to programmers to ensure they are aware of the software architecture and framework. On top of that, there should be code reviews to ensure there is not duplicate work. Finally, processes should be in place to ensure up-to-date programmers' guide are always available, training are given to every programmers and code reviewing steps will not be side stepped.
SIN #4: UNCONTROLLED CHANGES
Often we do not raise and eyelid when there is a request for changes to software. But that should not be the case. Because changes could affect the pillar of the system and we may not be aware of it. How do Building Architecture take requests for moving the pillar of a building, they will not agree to it. Though in software arena there is more flexibility, however, we should see be able to understand clearly, not at high level, the degree the changes have on the software. Especially when sin #1 and #2 are there, changes will always prove more complicated than expected.
There should be a standard process to handle change requests, so that the requests, discussions and solutions suggested are fully documented. The requested personnels are present during the discussion. Changes are thoroughly examined before providing a solutions. All possible options are considered. Work to make the software changes are started at the right time (not before approval from customers and not to long after approval either). Testing and reviews are done using the correct requests and solutions.
Often changes requested more then resources then initially expected. In such cases, the actual figure should be present. Else it may become the start of decay in the software system. If the changes causes increase degree in the complication of the software, we should be firm against the changes, especially when the software is used for multiple companies or when the changes is useful to a limited number of clients.
SIN #5: NOT FLEXIBLE
Changes is an inherit nature of software. Since changes is so common in software, every changes will be a challange if the software is not flexible. Programmers will generally create their own way of implimenting the changes. Hence inviting sin #2 and sin #3.
Hence a flexible framework is critical to a stable system; the higher the degree of flexibility the less the amount of programming changes, which leads to less bugs.
SIN #6: UNCOMPROMISING USERS
As competition heats up, customers have the advantage of demanding more and paying less. But is it really an advantage. When a customer is too uncompromising to their requirements and not willing to pay, software house may have to make unconventional changes to the software which is like a time bomb waiting to explode. However, if a customer is too compromising, they may not be able to receive the best value for their money. So the best is a balance relationship. To achieve that, there must be trust between the vendors and customers. Then everyone work for the common interest.
SIN #7: WEAK MANAGEMENT
Developing a software involve many groups of people, even for small changes. However, if the people are not able to work together for ensure a successful delivery, the final delivery will often break. Because changes today is to rapid and to such high degree that previous thought out processes and deliveries did conside some of the new changes. Together with the usual short time frame, teams often have to have the initiative and the capability to handle unexpected events.
Here is where management team are critical. They are required to lay done clear and effective processes and ensure everyone followed. Clear and effective job scopes so that problem will not slip in between teams. And an environment that pro creativity, quality and taking ownership. For this to happen, management have to play the leadership role on top of a managerial role. Only then can they propel a movement that ultimately become an effective culture in the department and company.
