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.

Right.

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.)

Comments: Post a Comment

Links to this post:

Create a Link



<< Home

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