I’ve been reading several discussions and articles on the topic of whether or not developers should test their own code, and I’m finding that the general consensus is, “No.” (Wait, it’s too early to stop reading! You must test!)
When talking about testing in this context, I’m referring to functional testing—not unit testing. There is absolute agreement in the development community that developers should write unit tests for the code they produce, and there is general agreement that functional testing by the authoring developer provides value, too. The argument that most of these discussions make against developers testing their own code is that the developer shouldn’t be responsible for putting the final stamp of approval on their output before it’s delivered to customers. This is very much in-line with my personal belief that one-developer projects are destined for failure, a problem that has been particularly prevalent on my development team.
I thought this was a decent analogy (taken from here):
Writing code is a bit like map-making.
You point your developers in the direction of some uncharted wasteland, supply them with coffee, and let them go hacking through the undergrowth. If you’re lucky, they’ll pop back up in a few weeks time, and they’ll have brought geometric exactitude to Terra Incognita. If you’re unlucky, they’ll go native and it’ll end up with heads-on-spikes and tears-before-bedtime.
Anyway: you want to test your new maps. The WORST people to test the maps are the people who wrote them. They know, without thinking about it, that you have to veer West when you reach The Swamp of Unicode Misery or you’ll drown. They know that the distances are slightly unreliable because they contracted malaria near the Caves of Ui and the resulting fever made the cartography kinda hazy.
In other words, when you develop a solution, you know how it was written to work, and you’ll have a tendency to test it that way. You know what the configuration settings are supposed to be, and you know when buttons are supposed to be pressed and when knobs should be turned. You are the one person in the entire universe for which your solution is most likely to work.
So that’s all good and well, but what can you do about it? It’s simple: get somebody else involved. Have a peer test your solution or demo the solution to others. These are great ways to find functional problems that you may not have considered. None of us is able to produce a perfect solution 100% of the time. It’s impossible to not make assumptions and not make mistakes, but getting others involved is a terrific way to overcome quality issues and oversights that can arise from those assumptions and mistakes.
Please feel free to comment on the subject. I’d love to hear what you think about this, particularly if you disagree.
adamprescott.net 
I agree 100% with this article. I do however want to ask, if you have no choice but to test your own software would you suggest giving it a wait period (E.g. 2 weeks?). I find that when I haven’t thought about the code for a while and try to use it, I approach it from a users point of view. Then because the code isn’t too foreign to me as it has been only two weeks, fixes are easier. Thoughts?
That’s an interesting idea. I think the successfulness of this approach would be largely depends on several factors, namely the number of projects/applications you’re working with, the scope of effort, and how much time you have to deliver. If you work primarily on a single application, you may find that you can’t get away from the code enough in a 2 week period to come back with objective eyes. If you only have 4 weeks to deliver a set of features, a 1 or 2 week self-feedback loop may lower your overall throughput or cause delays. So, depending on your circumstances, this may be a viable option, but I’d argue that finding somebody–anybody–is a better alternative. You may not be able to have them test the software all on their own, but demoing the software to them can be just as good. I’ve found that showing my wife software that she has absolutely no understanding of is a good way to expose usability issues. Along that same line, using people with no knowledge or experience is a great way to ensure you have an intuitive product.
Here’s the hierarchy I’d follow for getting somebody else involved. In a perfect world, you’d have dedicated testers that you can hand off completed work to. Subject matter experts (SMEs) with user/customer knowledge will be the next best thing. After that, I’d look for a peer developer. No peer developers? How about a non-developer peer? If you work for a company, there should be somebody who’s willing and able to help. (If there’s not, you may want to consider looking for a new company.) If you’re working for yourself, try to find friends or family. Offering food and drink may help with volunteers.
You’re right, most of my software projects are part-time things (Not a full time dev yet). When demoing apps to my friends I also get very self-conscious about what won’t work which helps. Thanks for the awesome response!
If you’re showing it off to a friend to get feedback like that, just be sure to set the stage. “I think this is done, but I’m still ironing out some bugs. If you see something that doesn’t make sense, be sure to let me know!” And, after that, expect them to be overly critical 🙂