Let Testers Do Terrible Things to Your Code

Jeff Atwood (you may know him as one of the founders of Stack Exchange) writes about how he learned to test his code:

"I believe a key turning point in every professional programmer's working life is when you realize you are your own worst enemy, and the only way to mitigate that threat is to embrace it. Act like your own worst enemy. Break your UI. Break your code. Do terrible things to your software."

He goes on to list (and link to) all the assumptions that software developers have about time, geography, names, addresses, and gender. When you're building a software product, it's possible to catch many, if not most of these misconceptions, but it's never possible to find everything. After all, if you didn't know about these problem areas, there are others that aren't on your radar.

What's a good programmer to do? Atwood says that you have to learn to break your own code, to be your own tester, and try as hard as you can to test beyond the limits of what you think users might do. Going through this challenge of your own creation is crucial for good programming. You're making something you want people to use.

"a good programmer knows they have to do terrible things to their code. Do it because if you don't, I guarantee you other people will, and when they do, they will either walk away or create a support ticket. I'm not sure which is worse."

This isn't even the worst part about having bugs in your software. The real tragedy is that the situation is entirely avoidable. Developers aren't great testers, they're too close to their code and have too much knowledge about how it's intended to work. They're the prototypical white box testers. Great programmers let someone else test their code.

The first step to writing better software and becoming a better programmer is to do terrible things to your code. The next step is to find good testers who will go through and check it for all the things you couldn't have possibly imagined.