I love the term “hype-driven development”, which I was reading about today (linked from Slashdot). It’s a tribute to those who have spent years honing and perfecting software development practices, and a much-needed wake-up call to those who have come after, have paid little more than a cursory glance to what is known to work, and still think they know better.

The “good” news is that it’s easy to get swept up in hype-driven development and to apply it to your own projects.

Hype is not only everywhere, it is also seen as necessary. Software engineers are overwhelmed by choice, and getting traction means getting people’s attention, which is getting increasingly difficult amidst the noise of everyone else doing the same for tools that are barely discernible from yours.

The reality of software is that once you get swept away with the hype, you start to invest in it. Quite often, this makes a lot of people very unhappy – particularly those left out of the decision-making process – long before that investment yields any return. By that stage, though, as a decision-maker, or an influencer of one, you’ll easily be able to nip this discord in the bud, and it’s hard to reverse that level of momentum.

Here are ten easy steps that you can take to get the ball rolling and to implement Hype-Driven Development for your project.

1. First, choose a new tool. Find somewhere that the tool is being used by a company everyone has heard of, as this generates “buzz”. Don’t be too concerned about what they’re using it for, or whether it relates to your work in any way.
2. When you start using the tool, don’t mention it to anyone until you’ve already decided to base your finished product on it.
3. Don’t bother finding out if the tools you already have can do the job for which you are employing a new tool. There’s no point being good at using an old tool because old tools just aren’t as interesting as new ones.
4. Expensive tools are automatically better than cheap tools. The price impresses the bean-counters, because so much software is free nowadays, and it makes it easy to measure fitness for purpose.
5. Even if you only plan to use the tool for a mild simplification to half a line of code that’s only used once, incorporating a new tool is still worth it.
6. Compare the tool by re-implementing some of your existing tasks. Only test the simplest and most trivial scenarios: if it works in a simple case, it’s bound to work just as easily in a complex case.
7. Any inconsistencies with existing standards can be readily overcome by creating a new standard that the new tool fits exactly. Try not to be disheartened by the idea that you’ve previously been doing everything wrong for years. If you’re not sure, rewrite the old tool to use the new tool.
8. Have some like-minded suckers re-implement everything even vaguely related to the new tool from the ground up. The more suddenly you can deploy this, the more of an impact it will have – and impact is always cool.
9. If the re-implemented product turns out to be awful, or if it doesn’t even meet the most basic requirements of your end users, you’ll be committed to the new tool by then, so it won’t matter. Tell anyone who is critical of the product that they should have raised their concerns earlier – especially if they did. By this stage, it will be too late to change anything, including the things you just spent a long time changing.
10. Stride confidently into your next performance review, knowing that even though you wasted a lot of time and resources to build a product that does slightly less than it used to, you’ve certainly achieved a lot.

Don’t be surprised if this shares a lot of traits in common with “résumé-driven development”, either. In fact, RDD may become the new buzzword to replace HDD one day; how fitting that would be.