Andrew Wulf runs TheCodist blog, is the lead iOS programmer for Travelocity, and owns Idle Diversions—an iOS game company. In this interview with Noel Wurst, Wulf discusses his role as a coder to "make testers miserable," the need for clean code, and practicing agile before it was a term.
Noel: You and I are meeting because of your blog, TheCodist.com, specifically, an entry you did back in March. "My job as a programmer is to make testers miserable." I saw the title, and I have to admit, your first sentence did not disappoint. "When I deliver something to a tester or a QA person, I want them to suffer terribly, to fear coming to work, to wish they'd never become a tester, to be drained by the end of the day." I love it. So, my short question to that long intro is simply—why?
Andrew: Quality comes from what the programmer does; if I don't deliver, no amount of testing can make it better. A tester's job is to make sure nothing gets missed, but they can't fix the problems— they only point them out. A baseball manager can encourage players, design strategy, and do all the right baseball things. But in the end, if the players don't hit, field, or pitch, then the game is usually lost. Likewise, programmers have to produce good code, ideally before a tester ever sees the end result. The idea that you churn out code fast and loose and expect the testers to find all the bugs never results in a good end product.
Before I ever worked as a programmer, I briefly had a job as a chemist where I worked for a product testing company. Whenever I was done with a test, I wrote up a report for the customer. The bosses complained I worked too hard on writing up a quality report, they expected me to slap it together and "the girls in the front office will shape it up." Besides the obvious sexist comment, it made no sense to me at all.
My job was to do the tests and deliver results to the customer. I think that experience impacted my work later as a programmer, in that I want what I deliver to be just about ready for primetime—even if it's only a test. That way the tester can focus on finding all the little things: the edge cases, and the nitpicky things that will drive customers nuts. If they push the first button, and the app blows up, then I'm not doing my job very well.
So if the tester has to work hard to find things (assuming they are highly competent) then I as the programmer am on the right track. I also think a tester needs to challenge the programmer to defend how things work sometimes; having more eyes look at the app is always a good thing and sometimes having to defend how you implemented something might make you think a little more about it.
Tester-programmer relationships have to communicate both ways; it's not about I code—you test, it's a team effort. By the time a customer sees the end result they should have no idea how the app was created because it works perfectly for them.
Noel: I quoted your blog in a recent interview I did with a tester who gives a session on alternative methods for awarding bonuses to testers. He recommends incentivizing collaboration between testers and developers, and other behaviors that lead toward eliminating what he sees as pessimism in the workplace that comes from "bounty-style incentives." I know you're a developer, and not a tester, but from your experiences with this "other species," do you see a reward program like that taking off, or being met with some skepticism?
Andrew: I don't really like creating artificial programs to try to make the tester-programmer relationship work better. Maybe I am idealistic, but after such a long career, I know the best programmers and the best testers don't need them. If neither is very good at trying to make them better with bounties or other means—it isn't likely to change much. Keeping both sides informed about what the customers are saying is more likely to be an incentive. No one wants to deliver a crappy app or whatever you are building. Just throwing money at people won't make it better; finding the right combination of people is going to pay more dividends. Of course that's not always easy, but I've worked with a lot of really good testers so they have to be out there.
Of course, managing development can screw up even the best combo of programmers and testers. I've seen where management decided to forgo QA because the customer thought it took too long and they went along with that! There isn't any better way to destroy a good team than not allow them to do their best. If the programmer-tester relationship is focused on getting the best possible result to the customer then random incentives aren't that useful.
Noel: I really like your thoughts on the need for "clean code," even if it's just a personal standard that you give for your own work, but it seems like there's almost a movement for clean, happy code. A developer I spoke to talked about the ability to "listen" to your code to see if it's "crying." He mentioned, "Code is talking to us" and that in many cases, design patterns in that code are "clearly telling us what it wants to do." With your love of clean code, do you also find it having that ability to tell us more than just "I'm error free?"
Andrew: Ever since I first learned to code I've basically been doing the same steps, and despite radical changes in technology in the ensuing decades, I get the same results today. I try out my ideas first, then I code in little steps and test each step until I completely understand what each one is doing—more importantly, that I have a plan for anything that can happen. It's not TFD or modern unit testing exactly, but has elements of both. It works for me and I still get the same level of quality in about the same timeframe. Maybe it's just a lot of practice!