Software Development: The Single Point of Failure
A Single Point of Failure in software development occurs when a key asset becomes unavailable or unworkable. This mainly relates to the loss of a skilled programmer. As a consequence software development will come to a halt.
This is obviously undesirable in any organisation with a goal of high productivity, living up to client expectations and meeting important deadlines.
So, if your prime resource falls ill, what are you going to do?
This is equally a problem for the Client who hires a programmer, but also for the Software Company having to support a Client's project.
Programming Resource Redundancy
For the Software Company, one way to avoid a Single Point of Failure is to have "spare" programmers available at a moment notice. But having redundant capacity is not practical. No development organisation can afford to have perpetual "spare capacity".
In reality, some degree of reorganisation needs to occur to fill the gap. Some Client has to lose out – and it is almost always the Client whose work has been halted.
If the absent programmer's skills are unique, it will be difficult to quickly acquire an adequate replacement. Many software applications require specialist knowledge to solve problems and to develop. It is seldom possible to make all team members an expert in every application. Programmers will have different skills and knowledge.
How to minimise the impact of a Single Point of Failure
The Single Point of Failure problem applies equally to a sole developer or to an organisation with teams of programmers. The mitigation remedies also apply equally to the single programmer or to a Company's programmers.
Having a bookcase of documentation is not helpful. But every aspect of the Visual Basic code must be documented, so that it is easy for a replacement programmer to be productive as quickly as possible.
Coding standards must be set at the outset and enforced. Again, the aim is to make life for the new arrival (as well as maintenance) as easy as possible.
Part of the standards should be to avoid wherever possible, unmaintainable, unmanageable code.
The Programming Language
The choice of Software Development tools is an important factor in reducing the risk factor. Selecting Visual Basic, the most popular programming language in the world, ensures that a replacement programmer can be found without problem.
The Operating System
Choosing Microsoft Windows, with its huge client base, ensures the technology is well known and easily available.
The Relational Database
Choosing Microsoft Access with its huge adoption – ensures the greatest safety.
Plan for this contingency from the start
The coding standards, the choice of operating system, programming language and database can all contribute in mitigating the risk of a Single Point of Failure.
These choices are all part of the development strategies that must be adopted from the word go.
Where bleeding edge, esoteric or complex development software is used, the Client should be warned (but seldom is) of the inherent dangers of risky software development. The least of which is loss of key players. Complex technology introduces many Single Points of Failure.
Protect yourself from the outset
Don't assume that somehow your project will be automatically, magically and adequately safeguarded from a Single Point of Failure.
- Demand to view the documentation on the coding standard to be used.
- Agree that on every major release (or on a regular basis) you receive a copy of the source code. This will eliminate later disputes on the ownership of the code.
- Have a professional inspect the code. For example, do the variable names adequately denote their meaning?. See the note Why have Visual Basic Coding Standards?.
This all applies equally to a software house or a sole programmer.