The first thing you have to understand is that I am old school. Back when I was developing software for a living we didn’t generally have people whose sole job was to test software. Certainly not in the unit test sort of way that seems so common today. We did have system testers and I was one of those for a long time. I developed software to stress test whole systems (including lots of computers and lots of potential timing problems). But while I had users using my software there wasn’t anyone, ever in my career, whose job it was to specifically test my stuff before it went into production or into customer hands. So I have trouble with this whole concept of groups were the ratio between people who develop software and people who test what they do is close to one to one.
I mean this whole idea of passing software from the developer to someone else without through testing and a good solid code review is just foreign to me. I’m not saying everything I ever wrote was bug free. Not at all. I threw the occasional side project together in a hurry or even made fast changes in emergencies without following the usual formal processes. And bugs did happen. And of course even the best process lets some bugs through now and again. And there are design flaws that pop in from time to time. But every time someone else reported a bug in my code I was both surprised and embarrassed. And yet today, it seems anyway, that many developers write code and expect other people to find and sometimes fix their bugs. Makes me want to scream.
I was discussing this with Clint Rutkas (an outstanding developer and all round great guy on my team) and he’s new school. He sees the value in this heavy test system. And he’s a smart guy and more in tune with current development in some ways than I am. But I don’t know. And then I saw this blog post – Non Obvious ways to find bugs – Look at the developer It complicates my thinking some more.
Briefly it is one tester’s characterization of different kinds of developers. These characterizations are scary but in fact these are types that have been around for ever. The difference is that in the past other developers and the managers of developers were responsible for keeping them in check and in helping them to get their heads on right. Now it is testers who do it. Is it better? Not sure. But let’s look at one type of developer and see where problems start. From the blog post:
Just out of College – these developers make alot of mistakes but they learn very very fast. They typically don’t test their code or they don’t know what to test for. Since they are so new to writing code for production, basically any testing theme will find bugs.
I was one of these once myself. In some respects one thing I had going for me was a lack of confidence. Yes a lack. It made me less afraid to ask for help and advice. It made me test my stuff like crazy. And it made me really pay attention to the code written by more senior and experienced developers. The very confident “I graduated from a name university and I am up on the latest theory” new hires could be just scary in what they turned out. But they would break a system build or their code would not pass the first review with either management or a customer and they would learn very quickly. Their mistakes were very visible beyond themselves. This was especially true if their code broke something (or things) built by other developers. There was no tester catching things before the developer could be embarrassed. Which way is better? Open question but the old way required fewer people. 🙂
The other categorizations are similarly interesting but to me they constitute of description of how not to be a good developer. The answer is not to use testers to find and fix the problems (or force the developers to fix the problems) but for developers to learn from these stories and not create the bugs in the first place. I am a firm believer in the lessons of W. Edwards Deming and one of those is that you cannot test quality into a product or system. I think people use all this extra testing as a way to avoid doing proper training and management of people.
What do you think?