Years ago, I attended a well-known SoCal art college. I had decided to pursue my love of painting and drawing, and see where it might take me. I had been given high praise by friends and family for the sketches I had done, and I was convinced that I was a skilled artist – yet, I knew something was missing, and I eagerly anticipated the art college experience.
My first semester of art school was an eye-opener. Not only did I have a lot to learn, but it turned out professional-level art was a lot of work. Harder yet was the process known as Critique, which lay at the heart of every project and assignment. We students would line up our completed works, often the product of hours of laborious brushwork, painful false starts and do-overs, and finally, if all went well and we were able to make our vision real, the true elation that comes from making something unique and beautiful with one’s own hands.
Nervously, I would await my chance to hear what my peers and teachers liked and didn’t like about my work. I learned how I had or had not communicated my ideas. I marveled at the assumptions people made in their own minds that were sometimes far from what I had meant to get across. And I learned to suck it up, turn disappointment to resolve, and welcome the gift of honesty I had been given.
Any software developer might read the above and find parallels. Who hasn’t experienced the elation of solving a particularly difficult coding problem, or creating that exciting new user interface that we just know our users will relate to? And who hasn’t also experienced the frustration that goes with seeing our users trip over minor bugs as if they were giant potholes, rendering all of our hard work, in the client’s eyes, useless.
I hate bugs. Bugs make good software look bad. Bugs make confident users timid and reticent. They can slow down the deployment of systems, and erode the relationship between the developer and the client. Despite all attempts at expectation-setting, convincing a client that bugs are just part of custom software development, and that they can and will be dealt with as they crop up, the expectation is that a good developer does not have bugs in their code. Not reasonable, but there it is.
Many developers like myself, who have been able to expand the size of their team, go for more developers as their first hire, or perhaps a project manager. Me, I went with a QC tester. I have never regretted that decision, and I have always had one on staff from that time. Every process with a finished product has quality control somewhere in the production chain, and software should not be any different. Developers are not any better at self-critique than artists. We are too close to the work. We know how it’s supposed to be used, so we don’t see how it can be misused. We fail to imagine the creativity of the user in breaking our product, just as the artist fails to imagine how others might see his work.
By having someone else test what I build, I get a glimpse into how an uninformed person with different expectations might mess up everything. I make sure my tester doesn’t know much – or anything at all – about coding, and I explain the business rules superficially when showing them what to focus on. Then I cut them loose, and am grateful to get the opportunity to fix bugs before they reach the user.
The system isn’t perfect. Over time, a QC tester will learn too much, and start to get too familiar with my work. A good one figures out how to make the most common mistakes – like changing the sequence in which steps are followed, or not filling in fields. They also learn what my most common mistakes are, and how to recognize them, which is also extremely valuable.
The upshot of having someone like this in place is that bugs are less likely to raise their ugly heads at the worst possible moment. I’m not saying it won’t still happen, it does. But there are fewer of them, and everyone – developer, client, user – can rest a little easier knowing someone is there critiquing the work and keeping its creator honest. This is a gift that cannot be underestimated.
