Why do we have testers? Why do we have PMs? Why do we have different disciplines at all? Isn’t it wildly inefficient? Why don’t we just have engineers who do whatever is necessary to ship quality products that delight our customers? Are programmers incapable of understanding customer needs or executing tests to verify their work? Of course not.
Eric Aside My introduction to this book chapter talks about how important it is to have a team of people with a diversity of skills working together on a project. That doesn’t mean those people need to be specialized into different disciplines with mutually exclusive responsibilities.
Yet, we somehow perpetuate these dysfunctional disciplines that create barriers, miscommunication, and conflict—also known as dependency death; handoff hell; black holes of blame; suffocating, senseless signoffs; and monotonous, mind-numbing meetings. Are we so insecure that everyone has to be “special”?
It’s not just ridiculous, it’s counterproductive. Devs and testers wait for PM specs, PMs and testers wait for code, and PMs and devs wait for test runs. Sure, there is always other work to do; but if everyone chips in on everything, then everyone is focused on the top priorities, everyone is a customer advocate, and everyone contributes to quality. It’s the team way. It’s the Agile way. It’s old school and it’s new school. It’s nirvana. What’s not to like?
Days of future past
Microsoft didn’t always have PMs and testers. We started out in nirvana and yet we strayed from paradise. Why? I’ve talked to old timers about it. Basically, not everyone wanted to do certain tasks, some people were better than others at certain tasks, and some important tasks weren’t getting covered. There was a need, and people started to specialize and fill gaps.
Of course, that was long ago. The market was different, our situation was different, and we were less experienced. But if we went back to everyone doing everything, would history repeat itself, and would people specialize once more? Is there a fundamental principle at work?
Unfortunately, yeah, there is. Specialization is unavoidable and essential.
Before you get too excited one way or another, let me make two points:
- The need for specialization is subtle; it doesn’t always apply.
- I’m right.
Take it to the limit
How do I know I’m right? Because of a great trick I learned on my high school math team. (Okay, I’m a dork. Let’s move on.) Here’s the trick: when you need to understand a broad problem, consider the extremes. In our case, the problem is optimal software development role structure. The extremes are coding an interview question and coding Windows Server.
When coding an interview question, you can do everything yourself. You get to know the customer (the interviewer), understand the requirements, spec the solution, code it, test it, and ship it. If you can’t, you don’t get hired. The moral of the story is that at the simple extreme, there’s no need for specialization.
Coding Windows Server requires many more developers. But do some need to specialize? Absolutely, there are parts of the code that are way too complicated for more than a handful of devs to understand. But do you also have to specialize in customer design and testing (either quality assurance or control)? Absolutely, but that’s harder to see because the scope of Windows Server is so big. Allow me to present far smaller example: an Xbox football game.
Football is a science
Coding an Xbox football game requires more than one developer. Again, specialization could be essential because of the computer graphics components, the AI components, the statistical components, and so on. But let’s skip to the PM and test areas. Do you need specialists there? Absolutely, but not at the tiny feature level.
Writing a football game requires you to know every detail about football: every rule, every play, every formation, every team, every stadium, every player and salary, and on and on. However, not everyone on the dev team needs to know all those things. In fact, most don’t need to know any of them. They’ve got other things to worry about, like computer graphics and AI. But someone needs to know—the game designer.
Someone needs to verify the results of the game. This person must be an expert video game player and football player who knows everything about how the game could be played and should be played. The complexity level is enormous, but it’s at a different level of detail than the implementation. The developers who write the code operate at a much lower level of detail. Even the dev architect deals with a different slice of the complexity. But someone must verify the results at the user level—the game tester.
Windows Server is far more complex than an Xbox football game. There are hundreds, if not thousands, of different experiences that must be completely understood, designed, and tested at the customer’s level of abstraction. I’d love to say that our engineers have big enough brains to keep all the details straight at every level of abstraction, and that they become refined experts about multiple, entire business models, module decomposition, and detailed implementation, but that’s flat out absurd. The moral of the story is that at the complex extreme, specialization is unavoidable and essential.
Eric Aside This is the part that’s lost on many Agile practitioners. Probably because there aren’t many Windows-scale products that make the case for specialization so clear cut. Again, I return to the knowledge I gained that projects need to be managed differently at different levels of scale and abstraction. What goes for the hundreds or thousands of engineers at the product level doesn’t make sense at the five-to-eight-engineer feature level.
The space between
So, what have we learned? At the simple extreme, specialization is superfluous. At the complex extreme, specialization is essential. Thus, the question isn’t, “Should we have specialization?” The question is, “At what level of complexity or abstraction do we need specialization?”
I claim that specialization is a waste of time at the detailed feature level. Devs should understand the requirements of the detailed feature (the spec, scenarios, and personas), then design it, unit test it, and code it. Testers and PMs stay out of specing and testing at the detailed feature level. If devs aren’t doing their jobs at that level of detail, then they aren’t doing their jobs.
I further claim that specialization is essential at the product level. We need PMs to really understand the customers inside-out, arrange communication between them and the team, and keep the team focused on the ball. We need testers to ensure the customer will be delighted. Not that the product just works, but that it works the way the customer needs and wants it to work.
Stuck in the middle with you
The big argument, then, is where to draw the line in between? When do you stop needing the separate disciplines? Can devs design and test dialogs or APIs? How detailed do you need to go before PMs and testers are overkill and counterproductive? Personally, I think it depends.
Where to draw the line depends on the product. If it’s a familiar product with an intuitive purpose, then you probably don’t need many specialists. If it’s an unusual product with an obscure purpose, at least to engineers, then you need more specialists. Complexity naturally adds to the burden and requires more specialty.
In the end, you should avoid specialization whenever possible. It adds a tremendous burden and drives dysfunction. If you have jobs anyone can do, like check the build or fetch pizza, then everyone should help do them. Anything less is selfish, egotistical, and unprofessional.
When you do need specialists, accept and embrace them. Give them the opportunity to learn, grow, and lead. Our success depends on it. Just don’t let it go to their heads. Work to avoid the pitfalls and barriers by using shared spaces, constant communication, and a focus on teamwork and team ownership. Remember: the team comes first, and pizza doesn’t fetch itself.
Eric Aside I talk about the impact of inappropriately combining development and test teams later in Test don’t get no respect.
Be First to Comment