Sponsored Link •
Dave Thomas: The other dimension to this whole issue—and this is something I feel very strongly about—is the stratification of job titles. The idea that you have business analysts, architects, designers, coders, and then people considered the scum, the testers, is a really major cause of problems in the industry, for a number of reasons. First of all, you have the problem that no one feels responsible, because it is always somebody else that's handing the stuff to you.
Andy Hunt: Or somebody that you're going to pawn it off onto next.
Dave Thomas: Right. You also have a phenomenal communication overhead. Every single thing has to pass up and down the chain. Everything has to be a memo. The business analyst to the architect, the architect to the designer, designer to coder, coder to tester, tester to coder...
Andy Hunt: And you lose signal through each interface, and introduce noise.
Dave Thomas: Right. You get this children's party game of telephone, where a requirement goes in on one end. Every time it gets transferred from one level to the next, it gets subtly distorted. You start out wanting an order entry system, and you end up with a payroll system by the time it gets down to the programmers.
Bill Venners: What is the alternative to stratification of job roles?
Dave Thomas: I don't think you can get rid of the layers. I think politically that would be a mistake. The reality is that many people feel comfortable doing things at a certain level. What you can do, however, is stop making the levels an absolute. A designer throws a design over the partition to a set of coders, who scramble for them like they are pieces of bread and they are starving, and they start coding them up. The problem is this entrenched idea that designers and coders are two separate camps. Designers and coders are really just ends of the spectrum, and everybody has elements of both. Similarly with quality assurance (QA). Nobody is just a tester.
What we should be doing is creating an environment in which people get to use all their skills. Maybe as time goes on, people move through the skill set. So today, you're 80% coder 20% designer. On the next project, you're 70% coder and 30% designer. You're moving up a little bit each time, rather than suddenly discovering a letter on your desk that says, "Today you are a designer."
Andy Hunt: If the designer also has to implement what he designs, he is, as they say, getting to eat his own dog food. The next time he does a design, he's going to have had that feedback experience. He'll be in a much better position to say, "That didn't quite work the way I thought last time. I'm going to do this better. I'm going to do this differently." Feedback paths contribute to continual learning and continual improvement.
Bill Venners: Continual learning is part of the notion of software craftsmanship?
Andy Hunt: Exactly. First you've got the designer doing some coding, so she'll do a better design next time. Also, you really need to plan how you are going to take some of your better coders and make them designers. As Dave says, will you give them "the letter" one day? Sprinkle some magic fairy dust and poof, they're now a designer? That doesn't sound like a good idea. Instead you should break them in gradually. Maybe they work with that designer, do a little bit of this design today, a little bit of that design tomorrow. Some day they can take on a greater role.
Dave Thomas: Also, typically organizations have a very hierarchical career path. If you start off as a coder, then your route upwards basically gets narrower and narrower up the tree. But that that doesn't really suit the human in us. Because the human in us says, "I don't want to spend all my time managing these people. I want to get my hands dirty every now and then." I would like to see a far more holistic approach to career, where you don't pigeonhole people into particular roles, but allow them to have the flexibility to do a little bit of this a little bit of that, just to keep themselves in the picture.
Andy Hunt: And you can see the problems that come from this division. You can see in most companies, as Dave said, the scum of the earth, the testers. There's a real division between people testing the code, when that's their full time position—"I'm a tester"—and the people writing the code—"I'm a developer". It sets up a natural antagonism between these two groups, which most of the time probably should be the same people, at least very closely aligned groups. Instead, these are like armed camps throwing stuff over the wall at each other. Anything that sets up that kind of adversarial relationship just doesn't work.
Come back Monday, April 21 for Part VIII of this conversation with Pragmatic Programmers Andy Hunt and Dave Thomas. If you'd like to receive a brief weekly email announcing new articles at Artima.com, please subscribe to the Artima Newsletter.
Andy Hunt and Dave Thomas are authors of The Pragmatic Programmer, which is available on Amazon.com at:
The Pragmatic Programmer's home page is here:
Dave Thomas was not the first person I've interviewed who mentioned the arcade
game Whack-a-Mole. James Gosling also called upon the versatile Whack-a-Mole
metaphor while pointing out that it is sometimes hard in
engineering to know if you've solved a problem or moved it:
The Agile Manifesto is here:
Ward's Wiki, the first WikiWikiWeb, created by Ward Cunningham, is here:
Extreme Programming: A Gentle Introduction:
XProgramming.com: An Extreme Programming Resource: