Nitpicking: development, agile and otherwise


Earlier today I twittered as follows:

It means I wasted a couple of hours with the API this morning, but I just heard that a @songkick feature I really want is in QA…sweeet!

Thanks to my ego-tastic monitoring processes, shortly thereafter I became aware of an indirect response to that tweet, along the lines of “‘In QA?’ What a waterfall thing to say.” While in my own defense the “in QA” part was a direct quote rather than my own formulation, the response did get me thinking about development processes for the first time in a while.

Not my own personal development processes, you understand, which run along the lines of “well, it didn’t seem to break too often running locally so let’s make it public and see what happens, because I’ve already been working on this for, like, a whole hour already” but rather those “people who don’t know me well enough to come by the house and punch me will be using this” development processes. Plus, a quick search also reveals that it’s been quite a while since I wrote anything about agile development, so I might as well go with it.

So here’s the context, for those of you too lazy to click through the links above:

  • I still love Steve Yegge’s pull quote from several years ago: “anything that calls itself a “Methodology” is stupid, on general principle.”
  • I still believe that taking an agile [or “Agile,” if you must] approach to software development reflects the most productive mindset currently out there, but that the key issue is the business buying in to this overall approach to making stuff, rather than software developers buying in to this overall approach to making stuff.
  • I still suspect that there are people who believe that “agile” is a magic bullet that will immediately, painlessly resolve all the fucked up problems that they’re having, and people who promote “agile” as a magic bullet that would immediately, painlessly resolve all the fucked up problems that everybody’s having [reference the ritual of the splitting of the list].

So How Does This Apply to QA?

I’m glad you asked. Whether it’s different people defining requirements, writing code, and testing, or a single person doing all of these, there’s a flow within an iteration. If it’s a 10 working day iteration and on day six you’re still spending most of your time on “what should it do,” you’re probably screwed; if it’s day nine and you’re still spending most of your time on “how should it do that,” you are#8212;again—probably screwed.

Even when the goal isn’t to get sign off and hand off in order to cover off one’s own ass, any piece of code is going to go through stages on the way to the happy land of flawless, bulletproof production. “In QA,” in this context, means that “what should it do” has been settled [and also that a few “what should it do next” items have been added since they won’t fit the time constraints], and “how should it do it” is largely settled for the developer [for the moment, at least, though “how could it do it better” may well remain an open question], and you’re on to the question of “so, okay, are we sure it’s really doing that?”

That doesn’t mean that no more code will be written, nor that a few more “oh, crap, I just realized that it should have done that but it doesn’t yet” items won’t be added to the list for an upcoming iteration, but rather that the organization—one person, three, or a hundred—is focused on confirming that the product or feature works according to the definition that they have agreed upon as they moved through the process.

Perhaps this is splitting semantic hairs, but I’ve lived through both scenarios, I’d rather be less “Agile” and spend time “in QA” than assume that “Agile” is taking care of everything.