"Breaking" code
"Breaking" code
Submitted by noreply@blogger.com (Michael) on Tue, 11/03/2008 - 20:12.Jason Gorman is an interesting guy, and has a lot to say. I agree with lots of it, especially his iconoclastic position on agilism. This time, I'd like to disagree with two paragraphs in a recent blog entry. The second one first.
But I suspect in 5-10 years' time, as test-driven development becomes more popular and teams become more ambitious in their testing efforts, test developers will be in great demand and will be able to command high salaries. I see them becoming as important as architects are viewed as today. Maybe more so, since they actually add value on a project ;-) (Only kidding)
This seems to have been coming up a lot, so I'll say it here: I'm agnostic about architects, but testers don't add value to a project; as James Bach suggests, testers help to defend the value that's already there, or help to identify ways in which value may be lacking. Testers raise questions and make observations; the people who make decisions based on those observations are the ones who add value. We help them do that, but we don't do it intrinsically on our own.
Realistically, you must be a developer before you can become a test developer, since learning how to create high quality code takes longer to master than learning how to write effective tests. That's not to denegrate the discipline of software testing: anyone who's read Robert Binder's book on Testing Object Oriented Systems will know that, if you wanted to, you could dedicate a lifetime to understanding testing. But, let's be honest now, it takes longer to learn how to code from scratch than it does to learn how to break code*. (* Is that my inbox I can hear filling up again?)
Well, first, testers don't break code; the code was already broken when it showed up. (I think I heard this first from Alan Jorgenson.) That's a fairly trivial objection, though.
The more serious problem is with the assertion that "learning how to create high quality code takes longer to master than learning how to write effective tests". Testing is not merely a matter of writing test code. Testing is about questioning the value of a product and the potential threats to that value. It takes the better part of a lifetime, I think, to understand value. Every time I think I have a handle on that, someone or something comes along to teach me another lesson in humility. But until we're sure we're able to ask the right questions about value, I'll contend that we can't know the right answers to whether our code is of high quality or not. By that reckoning, let's be honest now: learning how to create high-quality code and learning how to question should be inseparable. It's a rare person who can do either one very well, and even an even rarer person that can do both very well. That's why we need developers and testers—and why we tend to need a few of each.
But I suspect in 5-10 years' time, as test-driven development becomes more popular and teams become more ambitious in their testing efforts, test developers will be in great demand and will be able to command high salaries. I see them becoming as important as architects are viewed as today. Maybe more so, since they actually add value on a project ;-) (Only kidding)
This seems to have been coming up a lot, so I'll say it here: I'm agnostic about architects, but testers don't add value to a project; as James Bach suggests, testers help to defend the value that's already there, or help to identify ways in which value may be lacking. Testers raise questions and make observations; the people who make decisions based on those observations are the ones who add value. We help them do that, but we don't do it intrinsically on our own.
Realistically, you must be a developer before you can become a test developer, since learning how to create high quality code takes longer to master than learning how to write effective tests. That's not to denegrate the discipline of software testing: anyone who's read Robert Binder's book on Testing Object Oriented Systems will know that, if you wanted to, you could dedicate a lifetime to understanding testing. But, let's be honest now, it takes longer to learn how to code from scratch than it does to learn how to break code*. (* Is that my inbox I can hear filling up again?)
Well, first, testers don't break code; the code was already broken when it showed up. (I think I heard this first from Alan Jorgenson.) That's a fairly trivial objection, though.
The more serious problem is with the assertion that "learning how to create high quality code takes longer to master than learning how to write effective tests". Testing is not merely a matter of writing test code. Testing is about questioning the value of a product and the potential threats to that value. It takes the better part of a lifetime, I think, to understand value. Every time I think I have a handle on that, someone or something comes along to teach me another lesson in humility. But until we're sure we're able to ask the right questions about value, I'll contend that we can't know the right answers to whether our code is of high quality or not. By that reckoning, let's be honest now: learning how to create high-quality code and learning how to question should be inseparable. It's a rare person who can do either one very well, and even an even rarer person that can do both very well. That's why we need developers and testers—and why we tend to need a few of each.