Wednesday, December 14, 2011
Leveraging the worst developer to improve quality of enterprise applications
Before we get started, I must disclaim the fact that my idea will not work if the challenge of bad developers occurs in scenarios where consultancies such as Accenture have backed up the school bus to your enterprise and sent you more than one or two. That particular challenge is left for another blog entry.
A possible approach is to create a new role I will label as Project Saboteur which will be filled by your suboptimal developer. Their job is to check out a parallel copy of the source tree, and then introduce bugs on purpose. If you have a service that is supposed to return ten values, you deliberately hack the code to return eleven. In theory, every bug they introduce should be caught by an existing test. If not, you've found a hole. Categorize the holes, and you may find systematic weaknesses in the tests. Count the holes as a ratio of overall bugs introduced and you have a very rough idea of the percentage of bugs your tests are finding.
Since we know that this individual can't write quality code, we should leverage them in ways where we need to not write quality code. The art of defect seeding is something that can also test other enterprise processes such as whether the code review process is beneficial or strictly done to appease the PMO organization and is ceremonial in nature.
Defect seeding can be a better motivator for reviewers to more thoroughly seek out and uncover defects. Instead of it being a burden on the team to leverage an incompetent developer, it is better to turn it into a challenge where everyone is incentived to find many of the known/seeded defects. On Agile teams, this tends to add more synergy and zeal to inspection efforts...
Links to this post: