Software development - the journalism model

You probably don't know this about me, but I've studied journalism extensively. Back in third grade (for my vast international readership, that's the grade level you're in when you're ~9 years old), I learned journalism well enough that I think I wrote an article or two for my school paper. Maybe I even edited an edition of it - obviously, my journalistic credentials can't be called into question.

We learned that the essence of journalism can be found in the "Six W's" - Who?, What?, When?, Where?, Why? and, uh, hoW?. We also learned that teacher couldn't spell that day.

I humbly submit that these same Six W's should be applied a bit more rigorously to software development and project management, just in case you're trying to figure out if your project will fail or succeed (and if you're not trying to figure out, it will fail).

The Important W's

(in no particular order)

• What (are we doing)?

This one seems so obvious that it should require no explanation, but the flip side of that is that it's so essential that you're dead in the water if you and everyone else on your team can't explain what you're doing. The team should know what you (collectively) are doing in the macro sense and they should have direction in the micro sense.

If you or any of your team can't accurately (and hopefully, clearly and concisely) verbalize just what you're doing, your project's probably well on its way to being necrotic.

If you're a manager, you should be able to define achievable goals in the macro sense and the tasks needed to achieve them in the micro sense. If you haven't and if your people can't either, see you at the unemployment office.

• Why (are we doing it)?

As a lazy software developer, I pose this question to the project management team a lot more than they'd like me to. It's reflex and I think it does everyone a lot of good. I don't want to try to wield phrases I won't understand in a million years like "cost-value proposition" but they're probably applicable here.

In hackneyed colloquialisms I can wrap my pea brain around, whose itch will your software scratch? Will anyone take one look at it and immediately "get it"? Will it make people spontaneously say "this is fucking cool"? These are all really, really good things - if you know that people will think that it's fucking cool, you and your team probably does too, and will be excited and take pride in what they're doing, and the end product will reflect this.

Alternatively, will people take one look at what you've done and shake their heads and gasp in disgust at the turd you've fished out of the shitter and slapped on the table?

• Who (is doing it)?

As in - do you have the people to accomplish your goal on hand already? Or are you expecting that you'll just subcontract this out and everything will work out just fine? Do you already have a team of studs or do you expect scrubs to "step up to the plate" and get things done?

If you don't have faith in your team's ability to accomplish it, listen to that nagging voice in your head and start running for the hills.

Projects can overcome a lack of manpower, but you probably don't have the stomach or the wallet to grunt your way through it. With amorphous direction and unclear goals, even a team of ICFP-certified development gods are going to flounder.

The Unimportant W's

• How are we doing this?

This applies to those "little things" like IDE, language and framework. I don't mean to underplay the importance of all of these; you'll certainly make your work more difficult (OK, orders of magnitude more difficult) if you choose something pretty inherently unsuited for the task (RoR for an embedded system, C for a web application), but I also think that one of the other W's easily steamrolls it - Who. You put your team of studs up to the task and it stands a reasonable chance of succeeding in spite of itself.

• Where am I doing this?

This doesn't speak so much to physical location as to metaphysical location. Oh, did I just blow your mind?

By that, I mean things like version control (where the project lives), and build management. I'd lump bug tracking in here too. I know that Bill de hÓra would disagree and the developer in me wants to agree with him, but then I got to thinking - "hmm... VCS hasn't been around forever and I'm sure some working projects have teams that still pass around spreadsheets with a list of outstanding bugs on them." More importantly, the Who will overcome it - good people know good practices. If we walk into an shop without version control, we'll set it up. It's not hard to find a bug tracker out on the internets, it's a couple days to roll your own and if all else fails, spreadsheets aren't the dumbest way to go about things (OK, they kind of are). All this goes out the window once you meet a certain critical mass of project size, but the Who will obviate it again, as you'll get good people in there that will make you hire build engineers and all that jazz.

• When

Uh, now? I've lived through multiple dot-bombs, so spare me the "the market just wasn't ready for our innovation" speeches. See Why, jackhole.

Boiling it down to Solomon's Law (YES!), "Code cannot overcome reality." If the reality is that you've got an inept team, are lacking direction, are developing something that nobody wants, it doesn't make one goddamned bit of difference that you've got an A-number-one build system, magical bug tracking, distributed version control and an immaculate code base built on the right language and framework for the job.

No matter how beautiful the package, you're still boxing up a turd.