Fault Management

It's a bugbear of mine that error correction in software development falls into a twelfth-day mentality. Eleven days are spent building, constructing and 'working' and on the twelfth day someone is expected to make sure that it's all working properly. This applies to projects in general though, and highlights how for apparent immediate savings in time, resources are squandered across the project lifecycle by restricting our window of opportunity to deal with them. Here's some thoughts from a codemonkey's perspective, but the principles are pretty universal.

Identification of Risk

We've all heard of risk assessments, but in any project most of us will immediately be able to identify the steps in the process in which something is comparatively more likely to go wrong. It may be because of the complexity, time sensitivity or coordination requirements, the situations are innumerable but predictable. The first step to mitigating problems is to understand where they are going to occur. Sometimes awareness of the possibilities alone is enough to help you avoid issues and sometimes you need to plan for the most obvious contingencies.

Remember that the earlier in a project an issue is introduced, the more expensive it will be to remedy later (in terms of time if not actual monetary cost). If a problem does happen, and you're looking out for it, then you have a better chance of spotting and correcting it as early as possible. This really is half the battle. Understand your task and understand when and where things might go wrong.

Best Practices

While a number of issues can be averted simply by understanding their potential; many minor and often more significant things can be negated by implementing a methodology that actively avoids them. It might be adopting conventions in the way you code or always distributing e-mails to a group of people even when not all of those individuals strictly require all the information. Different tasks are sensitive to particular types of pitfall, and habitually avoiding that pitfall with a consistent application of process is really your most robust tool against trouble.

When a process or method fails to avert an issue, or falls prey to an issue you didn't see coming then alter the process. You may think that this is obvious but the number of times I've seen people fail to adapt to mistakes and shortcomings, particularly in the name of expedience and convenience, is staggering and saddening.

Peer Review

You're pretty poor at spotting your own mistakes. If you were great at it, you'd have fixed them already. Different people literally have a different perspective on any work, and getting them to look at yours will show up the things that your thought processes are blind to. Some people are big picture people and others are details people, and having both of those views on something can be essential to getting it right first time.


Testing should not be this final stage to a development or project. If you spend eleven months building something awesome and throw it through testing in a month you are doing it wrong. Dead wrong. All aspects of a project are eligible for testing. Errors happen at all stages of a project. Errors that occur earlier in a project cost more.

Testing done early in a project is the most efficient.

Everything from the projects initial set of requirements through planning and eventually implementation should incorporate an integrated testing approach. That is testers sitting with the available material and actually putting it through it's paces. This applies as much to documentation as it does a product and the training of testers gives them a unique insight into the ambiguity and interpretation of text as much as it does the suitability of, for example, app behaviour. Even things such as consistent use of terminology and language spotted at the time of writing can be critical in avoiding a mistake in execution.

Bug-free software or issue free projects of other kinds are about successful fault mitigation at all stages. Testing resources are just one tool to be applied throughout. There is no perfect, flawless effort but there's so much you can do to inch closer to that goal.

Movember 2011