Happy Bear Software

Guidelines for being an incompetent development team

Team getting too much work done? Not soaking up enough of that annual budget? Use these guidelines to make your team waste time and suck hard at delivering business value.

OFDD (Open file driven development)

When deciding where a certain bit of code or functionality belongs, apply the following logic:

  1. What file do I have open in my editor?
  2. Start typing the code in that file
  3. Commit the code

This technique allows you to hit the ground running in any new project you work on. Just start typing code and as long as it works, you win!

BDD (Buzzword driven development)

When faced with the choice of different strategies or implementations, favour ones that increase the total buzzword count of the codebase. For example, if your you need to manage a basic CRUD resource in your application, you have two options:

A developer that follows buzzword-driven best practices will always pick option two. Having more buzzwords in a project means you can use flashy words to impress your developer friends at meetups and conferences. This works especially well if no one actually knows what the buzzword means.

GDD (Google driven development)

For writing any new code, instead of thinking about the problem and coming up with a solution that best serves the known use cases, apply the following algorithm:

  1. Google the problem
  2. Look for a code snippet that solves the problem
  3. Copy-paste into the codebase
  4. Commit the code

A great benefit of this coding style is that you don't have to apply any thought whatsoever to the code. You just google, copy-paste and you're done! This saves on food costs, as your brain has to burn less glucose to get through the day.

MDD (Meeting driven development)

When building a new bit of software, there are many different approaches you can take. Two of them are:

By simply talking about the code instead of actually implementing it, you get to bill days of client time without delivering any software! The non-existant software will be bug-free and requires no maintenance whatsoever.

Sometimes you may get nightmare clients that demand non-imaginary deliverables, but they're not a lost cause yet. You can introduce them to meeting-driven best practices by adding at least six meetings per user story, daily catch-ups, weekly demos and fortnightly group therapy sessions.

Even then, you can continue to hold meetings and talk about the software in theoretical terms while other developers on your team actually do the work of building it. Since you were doing all the talking, you can take credit for it when it's done. While not as efficient as delivering no software at all, at least in this case you didn't have to do any work yourself.

FDD (Fascism driven development)

You're the manager of a high-powered department. You do important meaningless work and need a ridiculously large budget to go with it. To get more budget next year, you have to be as wasteful as you can this year to use it all up.

All of the best practices in this post work best when they're forced on developers. Instead of treating them like professionals and letting them pick their own tools and process, coercion from the outside makes your department more inefficient, allowing you to use up more of your budget for the year.

Some best practices that work really well when forced:

RGDD (Rube-Goldberg driven development)

This refers more to deployment process than actual development. When you have the option of choosing between more or less complexity in your deployment process, always choose the more complex option.

Having a labrynthian deploy process gives you multitude benefits:

As a pattern, Rube-Goldberg driven development works very well with Buzzword driven development. Creating a ridiculously complex infrastructure is a natural consequence of hitting your project in the face with every buzzword on the front-page of Hacker News.

Wrap up

There are other ways to suck terribly as a software team. The guidelines I've outlined in this post are just that, guidelines. If you implement all of them though, you have a real chance at being one of the most unproductive and incompetent development teams that anyone has ever worked on.