Focusing on prevention rather than cure

February 17, 2005  

It’s a vicious cycle. Disorganisation, lack of (or unclear) best practices, lack of communication – for whatever reasons many projects find themselves looming towards their production deadline with a large list of major bugs and change requests to complete. So they get everyone involved, fixing bugs. The application goes to production or trial production with the showstoppers completed but a few of the developers are assigned to fix the rest while the next release begins. The project gets larger, so they decide to hire some more developers and the bug list grows. Before you know it, bug-fixing is a full-time job for some unlucky developers and so juniors are hired because they’re cheap and the idea is that they won’t get bored fixing bugs. And so the others on the team are left adding business value as quickly as possible. Practices such as code reviews, unit testing, etc. get thrown out of the window – if they ever existed in the first place. And suddenly the whole focus of the team is not on prevention (of bugs) but cure (fixing them).

It’s a very deep ditch to be in – the business want their value for money now, they don’t realise that letting the technical team take some time to clean house will save them money and get them more value in the long-term. But they’re already spending extra money on full-time testers and bug-fixers so why would they allow that?!

Though there may be many on the team who can make a difference, most of all I think it is the responsibility of management to recognise this misdirected focus and take the proper steps to try and pull the team out such as:

Rather than hiring juniors, hire experienced (and experience in terms of depth not in terms of years) developers who appreciate QA practices and the chosen methodology;

Try to convince the business that they will benefit from a period of house-cleaning in which they see little business value but will benefit long-term;

Rationalise the bug-fixing / requirements process – maybe less bugs would require investigation if the requirements were clearer, or better documented, or better understood by the testers;

Most importantly, realign the focus of the development team to prevention: QA practices that will produce higher quality code and lower numbers of bugs through education (training, induction, knowledge-base, pairing, mentoring / coaching, presentations); altering roles & responsibilities; changing the structure of the development team; introducing new processes (this doesn’t mean the production of reams of documents); BVCs; continuous integration build; etc.

Of course it’s better not to dig the ditch in the first place. I have seen this situation many times and with a number of different project methodologies. I think what is important about methodologies is valuing the principles and using initiative to uphold them from Day 1 rather than following the practices, possibly blindly. I’m reminded of Bill Caputo’s recent blog on this. In my mind, methodologies consist of principles and practices: the principles being the values that the team should identify with and uphold (you can’t force values on people); the practices being the prescribed or suggested steps to take. You can follow the practices but if you don’t identify with the values and make adjustments to uphold them as necessary then you cannot expect everything to be rosy. Therefore, making sure that the whole team (business, developers, testers) value and appreciate the principles of the methodology from the start is the best prevention.