Mike Burns has some interesting thoughts on how non-testing code is trivial and it lead me to thinking about placing testing above development in the corporate heirarchy. In a normal organization, people start off in testing and maintenence and then only move up to development once they’ve proven their chops.

What I am envisioning is that everybody starts out as a developer and the development work is considered trivial and mindless because it’s aimed solely at passing tests. Once you’ve proven yourself as a good developer, you get promoted into testing. Once you start testing, you can’t ever write code again on that project and the job of the testers is to make the developer’s lives hell by making sure the code base is rock solid.

This has a number of nice features that I can see: First of all, it replicates the common “hazing” pattern that we know reinforces group solidarity. The job of the senior members is to make the lives of junior members horrible and junior members put up with it because they know some day they will get to do the same. (As an aside, there’s an interesting educational theory which says that bullying is a product of an age segregated education system. Before mass public education, children mainly interacted in mixed age groups with status based on age which was far more egalatarian because everyone at some point got to be the alpha of a group)

By forbidding testers and developers to communicate except through a chinese wall, it encourages both groups to form a unique culture and language which further enhances solidarity and cohesion. Additionally, the develop–>test heirarchy naturally encourages an evolution into develop –> test –> design which can allow for a much more organic growth into a design oriented company.

Of course, there’s a few downsides to this management structure as well: Development inherently requires more technical skill than testing and so it’s an inefficient use of expertise as those most competent at developing will be siphoned off. Additionally, not everyone is equally adept at both soft skills and hard skills and having a promotion path that moves from hardcore technical skills to people skills is only suitable for some people.

Say you’re a hardcore algorithms guy who loves working on scalability problems. You don’t want to move up to testing, testing is boring to you. Whats more, even if we let you become a senior developer, you’re going to get frustrated because all the smart programmers under you are going to move on.

Test driven management seems like an interesting way to structure a company and I’d be interested in hearing examples of people who are using something similar to this sort of approach.

Leave a Response