Minimal IT logo and link to home page
Research, training, consultancy and software to reduce IT costs
Home | About | Newsletter | Contact
Previous | Next Printer friendly
5 December 2006

Real programmers don't test

By Andrew Clifford

Some of the best programmers seem to do the least testing. Rather than criticise them, we should learn from them.

I have a guilty secret. Many years ago I told my manager I had tested a system when I had not.

It was not a large system -- it was an interface between mainframe systems and telex and fax software. I had been programming it for a few months. My manager asked me to do some testing. I was not really sure what he wanted, so I went away for a couple of weeks and did nothing. Then I told him it was all tested and we put it live. Thankfully, it all worked fine.

A few years ago I discussed my guilty secret with a colleague. He was a freelance contractor who was constantly in demand by my employer for the speed and quality of his work. He admitted he had the same problem too -- he felt guilty that he hardly seemed to do testing. And I found the same with another skilled contractor we used.

These programmers consistently produce high quality work. How come they do not seem to test, and get away with it?

There are a number of things that are going on.

First, these programmers are experts. They deeply understand the technology, tools and techniques that they use. Their effort is focused on meeting the real business requirements, not on the "how to" of programming.

Second, the programmers have a disambiguating mind. If the specification does not make sense, they clarify it. If more detailed design is required, they identify it and they complete it. They are mindful of edge conditions -- what goes in and out of their programs -- and make sure that these are clearly defined.

Third, and most important, they test as they go. They build test harnesses to exercise their code as part of writing their code. They do not think of testing as separate from coding.

Last, they continually integrate. They do not wait until they have finished a group of programs to put them together.

Of course the programs produced by these good programmers do need some high level testing. But they do not need more unit testing. The programs demonstrably meet their (clarified) specifications, and fit well with the programs around them.

These programmers have produced some of the best code I have seen. If you are a project manager, there are a few things that you can do to encourage this way of working.

  • Give your programmers access to whoever has written the specifications. Encourage your programmers to clarify and validate the specifications before starting the programs. If you say "here's the spec, just get on with it", no amount of unit testing will give a high quality result.
  • In your plans, do not split programming work into "code" and "unit test", because this can force programmers to work badly. Have a single "unit test and code" task.
  • Use progress reporting to encourage good practice. Report "coding complete, unit testing yet to start" as 0% complete. Report "unit test harness and test conditions complete, coding yet to start" as 80% complete.

Real programmers don't test. They don't have to. They already have.

Next: If you can't beat them, join them


To subscribe to the newlsetter, simply send an email to
Privacy policy

Subscribe to RSS feed

Latest newsletter:
Magical metadata

We use the term "metadata-driven" to describe IT solutions in which functionality is defined in data. Taking this to the extreme can provide unparalleled levels of speed, simplicity and versatility.
Read full newsletter

System governance

System governance helps you implement high-quality systems, manage existing systems proactively, and improve failing systems.

Try it for free!

Find out more