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.

Sunday, October 22, 2006

Crayons on the Tablecloth

After a hiatus (much needed both because of worky work stress and my first cold of the season), I'm back. On the topic of worky work, we shipped Taceo 1.7. It sucks a lot less now. It's still kind of nasty but so much better that I'm not so embarrassed if you try it. I should blog a little about what we actually sell and why consumers might want it, but I'll leave that until later. Maybe when I need a break from working on my Halloween costume.

I decided that before defining each job function more clearly I'd walk through a typical development cycle and try to point out everyone's roles. This installment is about that initial pre-pre-pre-design phase. Or maybe it's still design. Either way, it's the thing that comes before people even start to write specs or plans or schedules. Consider writing a rougher than rough outline of an idea on a tablecloth. In crayon. It's like that.

Yes, usually the concept is supposed to happen from napkins but I want to emphasize something beyond that. It's BIGGER than a napkin. It's more substantial. Ok, so who am I kidding? This is all about designs on a napkin. (Why is it that GOOG can't find any of the Picasso napkin sketches I wanted to use as links here? *grrr*)

Typically a PM has some idea of the product, the market, and how to help the product suit the market better. To the PM this is the goal. Fairly close, but there can be a lot of impossible demands from the blue sky PM.

Typically (after v. 1, at least) a dev has some idea of how to beautify and/or extend his/her code. And to the dev this is the goal. This is technologically possible but often totally disregards the customers.

These are two goals.

Two entirely different goals.

. . .


If you work where I work, this may seem all too familiar. It's not exactly desirable. But it's a common pattern. I know I saw it when I was borg, too.

Typically, test comes in after this point. I don't think it should but it does. I won't press this point but suffice it to say that there's something wrong with the pattern.

During the blue sky phase of a project lots of ideas are bandied about. Pm typically has a wishlist from particular customers and/or marketing. Most of which aren't feasible as written. Dev typically has some desire to refactor the code they've been saddled with supporting during the last release (because refactoring *always* makes everything better to the devs). Most of those cosmetic changes will take a very long time and add little value to the product. And test is usually left out. Mostly because it's still busy finding the bugs that the devs left in the last version of the product.


So that's how it usually goes. But how *should* it go?

It should be a partnership from the start. And PM/dev/test should approach a new problem with open eyes but with full knowledge of the limitations of whatever existing system. PMs specialize in being a cross-group/customer/marketing bridge. They do personal politics that are tempered with a fairly solid understanding, technically, of the product/component they own. Devs approach things from a more pragmatic code-focused point of view. They want to make the best software that they can to meet customer needs while requiring as little of their time later in the cycle to support it. Cleverness up-front will be rewarded by less scutwork later. Testers start to test every assumption made about customer demands or the market or some dev's idea of time-saving or even what group X *really* wanted. This saves them (and the rest of the team) time and money later. Together, all three flesh out what the spec should look like before the spec is ever written.

But, obviously, this doesn't always happen.

(P.S. Sorry if I'm a bit test-centric. That's my world at the moment. I've worn different hats in the past and I'm sure I will in the future, but at this time I'm a little too focused on being a tester at my startup.)

Saturday, October 07, 2006

The Three Legged Stool of Software Development

I gave up on "trinity" as the analogy pretty early on. "Tricorn hat" also didn't work. Nor did "three bowling ball holes" of software development. "Threepenny Opera" also didn't cut it. "3 Inches of Blood", while it had a certain appeal, also didn't quite work. So I finally settled upon the "three legged stool", so this blogpost is now hereby about the three legged stool of software development.

Why a three legged stool? There are three disciplines typically involved in the process: development, program/project management, and testing. Each of those disciplines has a role and each of those roles need to 1) exist and 2) be balanced with the others. Imagine a two-legged stool. For whatever reason, Google Images has failed me, so you'll have to imagine it instead of looking at a pretty picture. Without the third leg (you wouldn't believe the GOOG hits for "third leg" - unpublishable!), that stool is either going to fall over or have some outside force to keep it upright. Now imagine a three legged stool with legs of unequal size. All legs touch the ground, but the seat of the stool just isn't level (forgive me for the cheesy link, but I love that about SF!). In software development that just can't be right. So we try to have a stool with equal legs of dev, pm, and test holding up the seat of the software, of the customer. Keeping things on the level.

Synopses (I'll probably post more detail about these later):
Developers - write the code, fix the bugs.
PMs - drive cross-team collaboration, drive the design and the schedule.
Testers - test the code, file bugs, confirm fixes.

Those synopses leave out a lot of details. Everyone has equal input at all stages of the product cycle, for example (thank me later for no prescriptive/proscriptive PLC links so far). I should probably explain the product cycle and the duties within it before I go on too far. I really need to get into granularity of duties among leads, senior staff, and junior staff, too.

I'll just leave you with one of my favorite Patton quotes for now:
Lead me, follow me, or get out of my way.

Next up: Either a better definition on disciple duties, an overview of the product cycle, or my thoughts on leading vs being an individual contributor.

Sorry to anyone expecting more security geekery so far. If you want that, look only here and here. :-) My head has been too wrapped up in procedural junk at work to be worried much about security lately. Eventually I really will get around to the NT security model and how it compares to others in the industry or even to ideals.

Wednesday, October 04, 2006

I was going to post about my thoughts on developers, program managers, testers and how those disciplines fit together and I was going to entitle the blogpost "The Trinity of Software Development". Then I thought about it. On the bus. That's where I do my best thinking.

Why "trinity"? That has obvious religious overtones. And it would only be a matter of time until some atheist[1] came along and claimed it could all be done without any of the three. Not to mention the polytheists[2]. Really. I'm not going to mention them. Why "trinity" indeed?

So I decided not to post that long screed here. Instead, this is a placeholder for what I had intended to write. I think I'll pick some other tortured analogy instead. I think I'll go scribble something out on dead trees and post it later tonight.

[1] actually, from what I gather this was very similar to the early development org on the product I work on now. That's a long story and I don't want to paint too many black eyes on my workplace, though, so I'll skip it.
[2] I could start to make an argument that either consulting or working at a large software company might fit polytheism to varying degrees, but again I'll skip it.

Tuesday, October 03, 2006

Back to Real Life

This post wanders all over the place and has no real theme. Please forgive me. I'll post a more coherent post next.

I'm back from Ashland and I'm recharged. Mostly. The Shakespeare festival was wonderful. So was Mike's homebrew, despite its name (Goat Scrotum Ale).

Back here at work, we have about a week until we ship the new version of Taceo. There's a bunch of bugfixing, customer-pleasing (or at least customer-not-too-terribly-annoying-anymore) goodness in the internal builds. There are some really scary code-churning changes afoot now in the thirteenth hour, but with any luck everything will work out. Or we'll back the changes out and still be better off than our last release. Either way it's much better than what you might have already tried.

No surprise that nobody at work was celebrating today's holiday. I didn't want to mention it. I thought I'd seem too flip.

I recently found out that back at the borg the internal transfer process is now easier. That would have been nice during my time there. I can only hope that changes like that won't stop the hemorrhaging of talent that provides such well-trained, highly-skilled, industry-savvy staff for startups like ours.

For anyone in dev or test who happens to be reading my blog, you may want to check out Steve Pietrek's blog. He does a great job of collecting dev-interesting links daily, focusing mostly on managed code.

Since I'm rambling about almost anything, I'll also ask when the heck Terry Gilliam's new movie is finally going to open here in the US. Ok. Here goes . . . When? (Answer: October 6.) Days are getting darker here in Seattle and I'm shifting back into filmgoing mode. I've been waiting for a chance to see that film all summer.

End of rambles. Thanks for reading all the way to the end.

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