Monday, 4 April 2011

Development Methodologies

By now, everyone’s seen test-driven development (TDD), behaviour-driven development (BDD) and domain-driven design (DDD) – but there’s some other, so far development paradigms that haven’t got nearly the attention that they deserve.

Attention Deficit Disorder Driven Design (ADDDD)

Most commonly seen in open-source projects. You begin by implementing a core feature. After a couple of days, when either it gets boring or you’ve coded yourself into a corner and can’t work out how to get out, you pick a new feature and start implementing that one instead. Advantages of this approach are that you can tick “in development” on the feature comparison charts when evaluating your solution against the alternatives. Disadvantages are that it leads to crappy software that doesn’t work.

Attention Deficit Hyperactive Disorder Driven Development (ADHDDD)

Just like ADDDD, but features are only ever added in brief caffeine-fuelled bursts of manic coding, usually around 4am, accompanied by dozens of tweets, blog posts and Facebook status updates.

Developer Developer Developer Driven Development (DDDDD)

Projects are started twice a year, normally the week immediately after the popular DDD community event at Microsoft headquarters, and generally involves building something really ground-breaking like a wiki or a blog engine, just to “get your head around” all the amazing new stuff you’ve seen at DDD. You’ll generally lose interest about two days after you put the code up on Github as a “pre-alpha technology demo”, and then six months later you’ll do the whole thing all over again.

Advanced Dungeons & Dragons Driven Development (AD&DDD)

Everyone sits around drinking Red Bull, eating Doritos, boasting about their accomplishments and pretending to be some sort of tenth-level software architect when deep down they’re still not quite sure what a pointer is. A “dungeon master” (also known as a “project manager”) occasionally rolls some dice or reads a Gartner report, and then tells them that their project has died. Then they do it all over again, once every couple of months, sometimes continuing well into middle age.

Acronym Driven Development (ADD)

The HORSE of development methodologies; you consistently blame the failure of your last project on the fact that you picked the wrong methodology, and resolve to try something different on your next project. The conventional approach is to go test-driven, then behaviour-driven, then domain-driven, then extreme, then back to domain-driven. It’s a very educational way of wasting your employer’s time and money, and there’s normally someone in a back room happily coding away who doesn’t have the faintest idea what the rest of you are doing, but is probably shipping enough features to keep your company afloat.

5 comments:

Wayne said...

BDDD - Buzzword Driven Design, project is redesigned and started from scratch every six months to include all of the latest buzzwords

Mathias said...

Defect-Driven Design: instead of wasting time on specification and testing, just ship stuff. When the users come to you with their pitchforks because it doesn't work right, you'll know exactly what to work on next.

Mathias said...

... also sometimes named "Faith-Driven Development".

Matt C said...

Don't forget Mortgage-Driven Development (MDD)

Nick Gilbert said...

Argument Driven Development. Claim to your boss that almost every feature he's asking for is either a stupid idea, will be never be used, or shouldn't be there as nobody has asked for it and will lead to bloat. Only implement those features where the argument turned to voilence.