Keeping it clean, together
Imagine that on a highway, a car full of youngish looking people is going at a bit higher than the speed limit. That the group in the car seems to be enjoying the ride; they are singing songs and having fun. While they are eating some food, they are throwing the wrappers and left overs outside the car through the open windows. Now imagine that at a bit distance, a car is following it and is driven by another youngish looking person at a slower speed than the first car. That guy is cautious of the garbage being thrown from the car mentioned above and tries to stop every now and then to collect the garbage (a different type of garbage collection that what we usually study in memory management). Can that highway ever be clean?
(the original photo is here: http://www.telegraph.co.uk/motoring/news/9122019/Car-owners-face-fines-if-passengers-litter.html )
Now imagine that during a software development cycle, a group of youngish looking programmers are producing code at a speed higher than your anticipation. That the group seems to be enjoying the work; they are singing songs and having fun writing code as if coding is poetry (see at the bottom of http://wordpress.org/ ‘Code is poetry’). While they are adding more features, they are leaving some bugs and unfinished work casually. Now imagine that an iteration later, a youngish looking tester is testing those features at a reasonable speed. The tester tries to find every bug left over by the programmers and works hard to fill in any gaps in the quality of previously developed features. Can that software ever be clean?
The only way that we can the highway clean and the software clean is to bring among the whole team a concept of collective ownership. Such that no one throws garbage out the car in hope that others would be cleaning it. And such that everyone takes the responsibility of producing quality software rather than counting on the testing team.
Not that I’m advocating to getting into Quality Assurance business as Micheal Bolton has very strong arguments against it. But that the ownership of Quality is shared amongst the team rather than just the testers and one the five ways that James Whittaker recently suggested to revolutionize testing.
One of the ways to get this is to have a Whole Team approach in which everyone writes and runs the tests. The business facing people can define test cases based upon the requirements they get from the clients. The technology facing programmers can write lots of unit tests and can even go for the TDD approach. The testers can ramp up their role of writing tests by having more collaboration with programmers and business people and define end-to-end tests. Not that having more tests will give you a bug free software but it will certainly have the impact on the quality.
Do you see in your teams the above collective ownership of quality? If not, do you think that you need it?