Wednesday, December 14, 2011
Leveraging the worst developer to improve quality of enterprise applications
If you have ever worked in a large enterprise, on almost every project there is that one developer who is absolutely horrible that you wish they would just get rid of but due to HR, you are forced to put up with their suboptimal and ineffective coding abilities. Instead of focusing on how to get them bounced off the project, I believe there is a way to actually leverage them to improve the quality of software being delivered...
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...
| | View blog reactionsBefore 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...
