Wednesday, October 25, 2006

Put Away the Crayons

After that initial blue sky period which I prefer to think of as "huffing ether", we start to get down to the nity gritty. PMs drive writing functional specs. They *must* have buy in from dev and test, of course - t's that three legged stool thing). At that point, devs can ground the pm wish lists in reality and testers can try to find spec bugs before any code is ever written. Then simultaneously (ideally) dev writes up a more technical spec and test writes a test plan.

This is subject to a great deal of debate right now. There are many people calling for "agile development methods". Frankly, everyone I've ever known has used some of those agile methodologies whether they called them that or not. As someone focused on quality, I see the advantage in test driven development. And I've certainly led scrums in the past, though we didn't call them that. Whatever it takes to get a cohesive team building kick-ass software (just kidding with that last link). I'm not going to argue or belabor the point any longer. These things are as trendy in software as cargo cult efficiency methodologies are in *real* engineering.

While the devs and testers are busy trying to find ways to implement the master spec in their own realms, the pms try to guide them and start to push for schedule SWAGs (not those SWAGs, but these). Oh - and don't forget prioritization. Somewhere in this mess of people scurrying about, the pms drive prioritizing the work that will need to be done both in terms of the features set forth in the pm's (pms'?) spec and in terms of the actual work items for everyone involved (called out by dev and test in their docs).

Sometime soon after this, the devs and testers start coding. I'm not sure what the pms do at that point except keep asking more questions about schedule and priority. Oh - actually I *do* know. The pms do what they're infamous for - they try to push new features into the product. This is a continual process for them. It's why they're paid. Or why they seem to think they are. Frankly, feature creep seems like a sign of too many pms late in the cycle or too little pm thought early in the cycle to me. The venerable Brian Valentine is known within Microsoft's Windows division for the times during the product cycle when he declared that (my paraphrasing) "developers should fix bugs, testers should verify fixes and continue to find new bugs, and pms should get the hell out of the way". (Yes, any other fans of Patton out there might recognize this as being similar to "lead me, follow me, or get the hell out of the way". I leave it as an exercise for the reader to determine how close or distant BrianV was to/from Patton.)

Additionally, pms will drive cross-team initiatives. This is generally good news because it means that they're trying to make work for other teams and not yours. And if it's a pm from another team it's pretty easy to duck the work. Win-win for the people actually producing the software. If you're lucky your pm will prove to be a wonderful asset during this make-work phase because (s)he can be the bulldog that fights off other pms who try to take your time away from the job at hand: making all those new features work in less time than it is probably humanly possible. In a shop as small as mine is, that's not as likely, of course. But I'm writing mostly about economies of scale.

I should probably call out an assumption at this point: testers contribute to the bottom line. In many places testing is an afterthought. Preferably (IMO) not an after-market thought. In others, testers are integral to producing a product. In some (and I've seen/heard about them - they exist) testers are little more than a drain on everyone else's resources.

When things are balanced, I see it this way:

PMs - Gather requirements and drive prioritization and scheduling. They're the connection to marketing and customers when people wish for new features. They are primarily motivated by making "cool things" (which may or may not even be technically possible) happen.

Devs - Write the code. They are concerned with maintainability of their code base and understanding the deeper knowledge of what all their code does. They are primarily motivated by making "cool code" (which may or may not correspond to what customers need or want) happen.

Testers - Test the code. They are concerned with the stability/quality of the product and how it interacts with anything else out there. They are primarily motivated by not letting customers ever see any bugs (which is both impossible and tends to be contrary to adding the changes that devs and pms want).

Why do I start out with more silly links than I have toward the end? I think I usually begin in a whimsical mood and end on a much less whimsical one. I should think about this a little more and maybe change up my style . . .

Stupid sbemail link.

If it aint broke, why fix?
Post a Comment

Links to this post:

Create a Link

<< Home

This page is powered by Blogger. Isn't yours?