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.

Oral Traditions in Software Development

The requirements document will be the death of me. I don't have a whole lot of faith in the requirements document if only for the fact that I've yet to work with one that concisely and accurately expresses the needs and intent of everyone that it represents.
I can't stress this highly enough: I'm not very smart and I don't have much of an attention span. That's why "concisely" matters so much to me. You can make that requirements document accurate, but in the process you'll probably end up with something resembling the Yellow Pages for Manhattan. It's accurate up until the point where it puts me to sleep (about three paragraphs that resemble legalese in) and sooner or later, people will get hip to the fact that I didn't read it.
OK, I'm taking that a bit too far. I do read it as much as I think I need to in order to get the flavor of what I'm developing. People sweat way too much over getting into the down and dirty of how things are supposed to work, pre-chewing the details. For downstream consumers of this product (QA, client-facing folks and beyond) maybe this is a good thing? For me, I just want the broad strokes and I'll be able to fill in most of the blanks.
To fill in the gaps between the broad strokes, there's back and forth where I talk it out with the person who wrote the requirements document, because they know what we need better than I do. This works out great for everyone as we quickly hash out details and get back to what we need to do.
Well, it's great until months from now, when QA will have a new set of questions that weren't reflected in the original documentation because they didn't sit in the series of little meetings that development had with the requirements crew. And we'll have another sit down and chat and they'll see what the real intent of the functionality is or I'll go back to the drawing board.
Here's the thing - I really like how this works. Little meetings (30 minutes or so) when needed and when the particulars can fit it into their schedule. I don't have to read much of the documentation which is good for so many reasons, but mainly because people can tell me what they need better than they can write about how things should work.
But here's the other thing - I can see how one would look at this and be calculating a bus number of "one." The person that wrote the requirements document leaves the company and all of a sudden, you're back to just that dry document that's a subset of the expertise that they brought to the table. The developer leaves the company and all the discussions that the product developer had with them that they never inserted back into the original document disappear with it. People are left to scratch their heads over what's going on in with the application, not knowing that this is expected behavior.
Or QA or someone else walks into the application with the expectations laid out by the requirements document and finds that the fantasy of the documents doesn't meet the reality of the application.
I don't like documents.
I like talking things out.
I have no idea how to blend these two competing desires and turn what amounts to an oral tradition into a sustainable development model but if I figure it out, I figure I'll be a billionaire and then it'll be time to settle down to my life's ambition, hunting the most dangerous prey of all - MAN. Just fucking with you, I'll be so rich I'll pay someone to hunt MAN for me.

THE MOST IMPORTANT BLOG POST OF THE YEAR

As the internets tell me Paul Erdos famously told other people, "A mathematician is a device for turning coffee into theorems." I can't find any way to fault that logic. The man does, after all, know from logic and as far as logic goes, that shit is airtight.

My personal spin on this is that "A developer is a device for turning coffee into arable software." This, likewise, is airtight reasoning and to claim otherwise is to beg for your License To Internets to be revoked.

Inexplicably in the wilds of N'Hampsha, it gets hot up here. Sometimes ugly hot - about a month back it was 95 degrees and the relative humidity was at like 180% or something (before you furiously type and complain, remember that Erdos is the super-stud mathematician and I'm the forgettable developer). 9 months of winter and then we get this? So funny I forgot to laugh.

Days like these, I don't want home-brewed hot coffee, I want iced coffee. But who wants to buy iced coffee out at the coffee spots? With very few exceptions, I read "iced coffee" as "the shit that we brewed hours ago and didn't sell and it's too stale and bitter to sell hot but with a few ice cubes in it the rubes will drink it up." Lemons from lemonade and all that. But seriously - most iced coffee is bitter and stale. I've made my own at home by brewing hot coffee extra strong so when I poured it over lots of ice, it'd even itself out. Which works out OK, but I don't really want to turn on the electric kettle and boil water when it's that damned hot out. I just want some tasty iced coffee.

Inexplicably (oh, dissssss), it's the NY Times to the rescue with a recipe for cold-brewed iced coffee. But I've rambled on long enough and you don't need to read their snooty rambling in addendum to mine (you can if you want) and I don't know why they tell you to dilute the mixture.

For starters, the hardware - they have some retarded elaborate mason jar + cheesecloth + sifter combination, but fuck that noise. I normally make my coffee in a french press and I figure coffee's not going to get stale sitting out at room temperature (I'll experiment in the name of science on this soon enough, but my past experiments have shown the french press to work quite favorably), so if you don't already have one, maybe it's time to get one. Twenty bucks. Totally worth it. Makes hot and now cold coffee. Win.

So you grind the coffee (the normal amount that you'd brew with) as always.

And then you pour some cold water in (the amount that you'd normally brew the grinds with) and stir it up and, uh. That's sort of it for the steeping step.

THEN... it sits overnight. And in the morning, you push the press down and pour over ice and you win. As advertised, it's not bitter at all (you don't buy shitty roasts, right?) and adding a bit of heavy cream makes it almost candy-sweet. A little if you want but it's pretty damned fine all by itself over ice.

You've read this post, now you can safely turn off the internets because I can't imagine ANYTHING BETTER COMING FROM ANYWHERE ON THE ECHO CHAMBER OF THE INTERTUBES ANYTIME FOR THE REMAINDER OF THE YEAR.

Unless I decide to post again in which case all bets are off.

Agile Development - Can We Stop Designing?

Over on some programming forums I frequent, someone posed the following question that resulted in some heated development (from Agilists and others).
"We have a team that tells us that because they have adopted 'agile development' they no longer need to do any design work before writing code.

To me this seems bizarre, I can't fathom how one could build any reasonably complex application without a modicum of design (hell, even pencil sketches of UIs or something), but they claim it works.

Is it reasonable to develop complex applications with zero design work?"

BUFD (Big Up-Front Design) has gotten a hell of a black eye, but damned if I can think of a better way to wrap my head around a project in a business domain that I'm completely unfamiliar with.
Generating documents is a mixed bag - I think they're great for the process you use to create them (collaborating with everyone involved in the project, picking brains, exposing flaws and needs and hopefully constraints early) but I think they're awful for the fact that the end product is a document that's outdated a week into the development process (give or take; the point where the bulk of your time is developing rather than documenting) and at that point, the different partners have vastly different ideas about what the document means.
Developers think it's a rough roadmap (do I update the documentation with the way things will work in our system? I'll get that later... OK, not really. Have a meeting? That gets old REAL fast), most everyone else (project managers/QA/stakeholders) think it's litany and that's a sure-fire recipe for friction.
Eschewing the design portion of this and flying by the seat of your pants elevates this from an exercise in friction between developers and, well, everyone else to an exercise in sure-fire catastrophe for everything but the most trivial of implementations.
This isn't to say that reasonably complex applications can't be done without BUFD - I'm sure that they can, but with a big fat caveat: the developers have had a reasonable amount of experience with the business/application domain that they're developing for. There you can come away with a working application in the void of BUFD but with yet another gotcha: no one has any solid expectations of what to expect when the developers pull away the veil.
If you're working in an "agile" fashion, I guess this means that you're going to have rapid iterations from developer to project managers/stakeholders at which point they'll yea or nay it and talk about what else needs to be done, which probably means throwing away a fair bit of what you're doing, which means that instead of doing BUFD, you're doing Smaller Bits And Pieces Of Design All Allong (SBAPODAA). On the upside, there's that boost of "look what we're getting done". On the downside, there's that "holy crap I had to throw out another fucking day's work because Joe Blow From Product Management couldn't have told me yesterday that's not how things work?" and on the real big downside, there's the very real possibility that you're going to scuttle the project wholesale because developers are arrogant and think they know how to do everything so much better that you end up with a brilliant application that just happens to be absolutely useless for what the stakeholders need it to do.
I'm pretty sure that pair programming doesn't solve that one.