Over the month of August, I’ve been exploring and naming some of the development practices I’ve seen (and, in some cases, done) in my career to date. Here they are all in one place.
ADD is for Agile Driven Development. It is usually caused by senior management insisting the organisation must “Do Agile” because a consultancy sold it to them on a buzzword bingo card. The result is a disdain amongst developers for what agile development really is.
BDD is for Bureaucracy Driven Development. It is caused by someone whose job is literally to make yours more painful. The consequence is that it forces developers to do what is least inconvenient, not what is best for the organisation.
CDD is for Coverage Driven Development. It is caused by a development lead setting a quality gate at 100% coverage, seemingly unaware that “covered” and “tested” are different things. The result is a false sense of safety when making changes, and more unstable software.
DDD is for Deadline Driven Development. It has several causes, usually involving someone’s inability to say “no” to their boss. The result is code hacked together with the intent to be fixed at a mythical point in the future called “later”.
EDD is for Ego Driven Development. It is caused by someone who, in the false guise of being “clever”, makes a simple piece of software needlessly complicated. This developer will boast about the “complexity” of this problem, while the underlying code never gets touched again.
FDD is for Fire Driven Development. It is caused by software that, due to other poor practices, has become more brittle than an antique plate, and thus requires constant firefighting. The scorched code that gets added every time adds little fireproofing.
GDD is for Guess Driven Development. It is caused by a requirement spec that amounts to “replicate the existing system”, with no detail on said system. The result is ages spent reverse engineering, and anger from the PM for not replicating a bit he didn’t tell you about.
HDD is for Habit Driven Development. It is often found in teams that have been doing things the same way for years, and they feel no need to change it because “it works”. These teams often wonder why they face the same issues time and time again.
IDD is for Innovation Driven Development. It stems from a desire to use all of the latest and greatest technologies in your software solution. Sure, it may do nothing of value for your client, but it does nothing in a cool way, which is what really matters.
JDD is for Jargon Driven Development. It is caused by senior management specifying system requirements in the form of a buzzword bingo card. The result is a “scalable, event-driven, hybrid big data visualization agile cloud container”, whatever that means.
KDD is for King Driven Development. It is caused by a manager who has let the power get to their head, and who junior developers do not have the courage to challenge. The end result is low morale, low productivity, and more bugs.
LDD is for Length Driven Development. It is most often found in organisations whose chief measure of developer productivity is amount of code committed. The result means, and quantity goes up, quality goes down (and not asymptotically).
MDD is for Magic Driven Development. A good magician never reveals their secrets, and neither does a good developer. They are a wizard at writing needlessly complicated software, and are usually the first to be called at 3am when it breaks and nobody else knows why.
NDD is for Name Driven Development. It comes from management defining the name of a software system without defining, even broadly, what it does. The result is something that said management may or may not want, but we don’t really know for sure.
ODD is for Optimisation Driven Development. It is triggered by a desire to squeeze every possible performance gain or resource usage possible as part of the first release. The result is usually a software system that is very efficient at doing the wrong thing.
PDD is for Politically Driven Development. It is usually practiced by mediocre developers who wonder why they haven’t got their next promotion yet. Like a true politician, they rack up significant amounts of technical debt for the next generation to pay back.
QDD is for Quest Driven Development. It’s led by the false belief that there is such a thing as the Holy Grail of perfect software. Like any quest for the Holy Grail, all practical considerations are forgotten (like what the client actually wants).
RDD is for Rules Driven Development. It comes from the idea that end users will want to configure a rules-based system to perform their business functions. The result is a rules-based system so complex that not even developers, much less end users, know how to use it.
SDD is for Speculation Driven Development. It is most often practiced by people who don’t feel the need to investigate the real causes of issues in their software (they wrote it, so of course they know what it is). The result is that said issues are never fixed.
TDD is for Thread Driven Development. It comes from the ill-informed belief that all performance issues can be solved by throwing more parallelism at the problem. The result is usually performance issues that end up being worse than the one you started with.
UDD is for Urgency Driven Development. It comes from salespeople who believe every client feature request is “urgent”, and that telling them to “hack it in” will result in faster delivery. The result eventually becomes a stack of plasters, resulting in unhappy clients.
VDD is for Velocity Driven Development. It comes from the myth that all story points are created equal, and that completing X points in one sprint means X must be done in the next. The result is developer burnout and stories with missing pages.
WDD is for Web Driven Development. It is practiced by developers blindly copying and pasting code snippets they see on programming sites without fully understanding them. The result is a patchwork of code never intended for your use case, littered with unintended consequences.
XDD is for Xerox Driven Development. It comes from someone thinking the best way to re-use someone else’s code is to copy and paste it into their own, bugs and all. Later, once someone fixes the bugs in one version, they question why their fix doesn’t work in the other.
YDD is for Yes Driven Development. It is caused by development teams blindly taking on new features without understanding how said features will benefit the customer. The result is a system that does many things, none of them well.
ZDD is for Zero Driven Development. It is based on the belief that the static analysis tool is always right, and that no warnings means perfect code. The result is confused code resulting from fixing false positives, and a false understanding of what good quality code actually is.
