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:
- What file do I have open in my editor?
- Start typing the code in that file
- 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 basic
ActiveRecord::Basesubclass with the standard resourceful routes
- A single-page application using redis for sessions, resque for the job queue, MongoDB for persistence and Hadoop for well, whatever. All deployed to the cloud using chef, puppet, ansible, docker and vagrant with extra paradigm shifting synergy.
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:
- Google the problem
- Look for a code snippet that solves the problem
- Copy-paste into the codebase
- 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:
- Figure out the requirements for the first iteration and start building a prototype.
- Talk about the project. No really, just talk about it without actually building it.
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:
Forced pair-programming - particularly good when you pair experienced developers with those who are happy to stare into space all day. The experienced developer gets a rubber duck and you get to use up more of your budget. Also wonderful when personal hygiene standards on the team are low.
Forced meeting attendance - The less valuable the presence of the developer in the meeting the better. This allows your developers to practice the art of tuning out of meetings and focusing on interesting real-world problems while paying just enough attention to seem as though they're listening if addressed.
Forced insecure software - When you have a feature that is flagged as fundamentally insecure by a developer, make them build it anyway. It doesn't really matter if it's insecure, but if it is, you can blame the developer and get budget for security consultants when your infrastructure is compromised!
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:
Since only the developers who built it will understand it, this affords them a great deal of job security. They can demand higher salaries, which makes them high-power employees in your high-power department of incompetent heavy-hitters.
By making deployment an 18-step process that takes days rather than minutes, you further decrease the efficiency of the team, allowing you to ask for more budget and expand your department. You can spend entire weeks on problems that deliver no business value at all!
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.
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.