How Not To Develop Software

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?

Comments (2)

  1. Jon Schwartz says:

    I agree, and would add the test-driven development ought to be taught in the classroom.  It seems like that’d be hard to do that until college – but it certainly should be taught there.

  2. Rob Miles says:

    Hear Hear. And Hear Hear again. (I’m old school too). I wrote and sold code just like you Alfred. We didn’t have testers as such, I just make sure it worked before I handed it out. Very occasionally I had bug reports, and I always took them very seriously and fixed them real quick.

    When I first heard about how a virus infects a system by doing things like buffer overruns I was amazed. I’d never, ever, written a program that was susceptible to this kind of attack because it was obvious to me that this kind of thing could happen. I’d even noticed that the C input/output libraries had inherent behaviours that make buffer overruns possible if you use them, and so I wrote my own I/O that I used for my code.

    I’ve never thought that splitting the testing and developing process was dangerous until you mentioned the point today. I would never hand off code with the thought "Oh, if there are any bugs the testers will find them" and it scares me to think that this is happening at the moment.

    I teach programming and the first thing we do is metadata (establishing the scope and the bounds of the problem domain) and validation (using metadata to make sure that data going into the program is sensible according to the metadata we have gathered).  We move on to test driven development in the second semester of our first year. The only problem with teaching test is that it is very hard to do if you have a Graphical User Interface, but I tell my students that this means that you should just factor the solution so that the UI is a thin layer in front of your business behaviours, and then make a test harness.

    I also make the point that you should plan to spend at least as much time proving your program works as you do writing it, and that the quote you give the customer (if there is one) should reflect that.

    The fundamental principle here is "make sure that the (insert bad stuff here) falls on the other persons’ head".  It should not be possible for your code to be broken. Before it goes to test.

Skip to main content