The other day I found an old article written by Joel Spolsky. Probably not someone most people have ever heard of, but if you work in tech you’ve benefited from his work. Among other things, he’s the founder and CEO of StackOverflow. People go to StackOverflow to ask and answer all kinds of technical and coding questions. Believe me when I say that without StackOverflow there would almost certainly be fewer games out there. He’s also behind other tools by the names of Fogbugz, Trello, and Gomix. My point is, he’s quite accomplished. That makes it so much more satisfying for me to see this piece that is all about the importance of testing.

Top Five (Wrong) Reasons You Don’t Have Testers

Even though this article is from the year 2000, it is still stupifyingly relevant and something more developers and engineers should be familiar with. I almost never thought I’d see the day.

In the year 2000, an Engineer will respect Testing

Joel Spolsky’s 5 Reasons

In this article, Joel Spolsky gives some background of technical problems he’s encountered, and gives a run down of what he sees as main fallacious reasons that places don’t hire testers.

1. Bugs come from lazy programmers – If programmers know that there are testers, they’ll feel free to be sloppy
2. My software is on the web, I can fix bugs in a second
3. My customers will test the software for me
4. Anybody qualified to be a good tester doesn’t want to work as a tester
5. I can’t afford testers

Joel gives explanations and tear downs for each line of reasoning. I am going to add some of my own comments here, and add a couple more fallacies not only about testing, but how it is incorporated into development.

Bugs come from lazy programmers

This is a laughable assertion. As Joel Spolsky points out, it isn’t being lazy that causes bugs, but rather the unknown. I often say that there is no software beyond trivial functionality that is bug free. There are always edge cases, race cases, and crazy collisions of functionality that can cause errors. The more complex the software, the more of these interactions can be problematic. Simply taking care when coding will not root out all of these issues. Users will always expect to be able to use your product in a way you didn’t anticipate. For example, many years ago I was using a bug tracking program that would crash if I had 2 instances of it open, and used a certain function on both at the same time. That is not something an engineer would think a user would do, but I wound up doing it all the time.

The reality here is that engineers and testers have inherently different points of view. Engineers create where testers try to break. Both efforts are in service to the product, trying to make it better. However, these efforts are adversarial with each other. You can’t expect someone generating the product to be able to put their full creative force into making sure it doesn’t break. This is the same reason writers shouldn’t edit their own work.

My software is on the web, I can fix bugs in a second

Joel Spolsky rightly points out that while web applications, or web sites, can have issues fixed quickly, that doesn’t mean the fix won’t cause more bugs. Testers are needed to not only verify that a bug is fixed, but also that surrounding functionality still works. It doesn’t help if you fixed your SSL certificate if you malformed it and brought the entire site down.

On top of that, you don’t want to have bugs out there in the first place if you can help it. You want to try to iron out any issues while staging the app, or site. If there are issues and the product is public, it must be affecting customers. If that happens, then there is a delay between the customer noticing it, and notifying you, then for you to fix the issue, then for you to apply the issue, and then for the fix to propagate around the world. DON’T discount that last one. Depending on what happened, a fix may be instant, or it could take hours, or even a day. So, no, you can’t fix everything “in a second”.

My customers will test the software for me

Joel Spolsky gives a tremendous story about Netscape always releasing untested beta builds to the customers. The customers would then report issues to be fixed. While that was going on, the “official” releases would be fairly solid, but so many people had the “unofficial” releases, they simply thought the product was buggy.

It doesn’t matter if you don’t call it an official release. If you release crap, people will think it’s crap. This is still true today. How many people get up in arms when an early release game changes? Too many. They don’t see it as a game in flux. They see the game as something the purchased, and changes can be unwanted, even if they were planned the whole time. Heart attacks in Darkest Dungeon, anyone? These are two sides of the same coin. That being that the perception of the consumer is very important, and should be cultivated with care.

Pages: 1 2