Making Testers Miserable: An Interview with Andrew Wulf


To me you have to find a personal style and rhythm that works for you and gets the desired results. I have never bought into the idea there are magic bullets that can make anyone a great programmer. Programming is a combination of imagination, creativity, experience, tenacity and discipline. I still have no idea why some people master programming and others fail miserably. It isn't intelligence or some easily definable or discernible set of traits. If it were easy, everyone would only hire perfect programmers.

Of course the quality of code is more than just a lack of bugs. My favorite definition of quality in an app is "it does everything it is supposed to do and nothing it isn't supposed to do". Quality of an app is something best measured by the customer. But quality of code should also include maintainability and understandability if that's a word. Testability of course but there are many levels to how you test an app. Performance and other optimal runtime behavior is also a quality. A final measure might be how long it took to get to that desired combination of qualities but that's often the one thing that might take longer than you like.

Of course, if you can write code, keeping all these desired items in mind and still deliver them to the testers already in place, then you're doing great! That's the ultimate goal, but of course it isn't all that easy to do. But, if you aren't hitting any of these qualities, then maybe you need to find a different approach.

Noel: Another blog post of yours I really enjoyed was, "How I Did Agile Long Before it was a Thing." I actually hear this from time to time from developers who have been coding for decades, and it always makes me wonder, if people were "doing agile" that long ago, it made sense then like it makes sense now, why did waterfall-style development ever take off, thereby keeping agile "under wraps" per se, for so long?

Andrew: My first job was at a defense contractor and my first project there was clearly what we know as waterfall today. Of course, that name didn't exist yet, the term first appeared in the mid 80's as an incorrect description of a diagram in an article written in 1970. But that was actually the last time I ever did anything in such a stepwise fashion. Over those three years, everything was far looser and less organized. The projects I worked on were small and not simply writing some big application. So I learned how to organize on the fly and even do multiple projects at the same time.

In my first startup in the mid-80s, and in the following nine years where I lead three mainstream application teams, the other programmers and I never spent much time thinking about how software should be developed. I don't think we even realized that people studied this as a topic! There was no Internet and there were few sources of information to tell you how to do anything. You had to figure it out for yourself.

Agile is basically about communication and taking development in small steps. I think that's basically what we were doing even at the start. By the last application, Deltagraph (charting), where we spent five years delivering five major releases, we had figured out a comfortable way to make development happen. I basically operated like a spider and kept communication flowing in all directions between the publisher and my team, as well as coding.

We switched gears on features almost every day. Basically, we ran an interactive feedback loop. There were no static structures at all like you have today, no sprints or boards or anything. It was all people keeping information flowing by talking. We didn't even have email (we were in Texas; the publisher was in California) we had only phones and FedEx.

About the author

Upcoming Events

Oct 01
Oct 15
Nov 05
Nov 05