Development Pattern TLAs
3 minute read
There are many common three-letter acronyms (TLAs) used in the software industry; TDD (Test Driven Development), BDD (Behavior Driven Development), DDD (Domain Driven Design), etc. However, there are a few lesser-known TLAs we should be aware of.
JDD
Jenga Driven Development is the haphazard approach to building systems where no thought is given to sustainable delivery. Eventually, the system becomes so fragile that it’s too dangerous to change. At that point we knock over the tower, “modernize the tech stack”, and hope we get different outcomes.
Credit to Antonio Cangiano for this gem.
RDD
Resume Driven Development is the approach used when the primary goal is to expand the technologies we can claim to have used rather than delivering value. The indication for this is tech stack and architectural complexity.
“What language are you using?”
“With our event-driven, micro-service architecture we aren’t constrained to a single language like less evolved teams. We use C#, Golang, Node, Python, Clojure, and Haskell. Our UI framework allows us to use Angular, React, and Vue. We like the flexibility.”
“Wow! That’s impressive! What does your product do?”
“It’s a recipe organizer.”
CDD
Conference Driven Development is what happens when we (or executives) get excited about the shiny new things seen at the last conference. The outcome of this is that we stop everything we are doing to re-architect our system, move everything to the cloud, rewrite everything using Qlang, or chase any other process/technology shown on stage to replicate their outcomes without regard to our own context or all of the problems the presenters didn’t talk about in 30 minutes of marketing.
PDD
Process Driven Development is when “how” we work is more important than the outcomes. An example of this is any “Agile Framework™” that includes metrics for how well the framework is being executed.
DDD
Deadline Driven Design. Related to JDD, but implemented much more rapidly. Deadline Driven Design is what occurs when we pull out all the stops to have teams meet a fixed (or expanding) scope and date project and pressure them to ignore things like testing, feedback loops, and basic design practices so we can “make the date”. We declare success on delivery and hope we can get a promotion before anyone notices the outcomes. This always ends in tears and often for many years afterward, but only for the teams. Anyone who can get another job will.
GDD
Grenade Driven Development is the pattern we use when we want to ensure we distribute responsibility as widely as possible by creating functional silos.
Requirements are written and lobbed at development. Coding is completed and lobbed at QA. Testing is completed and lobbed at Ops. Finally, the grenade blows up in the face of the end-user and everyone points at everyone else. Success!
FDD
Factory Driven Development is the process where we send requirements to a feature factory coding mill and expect them to be implemented quickly and without question. Programming is just glorified typing, after all.
“Stay in your lane, Code Monkey.”
MDD
Management Driven Design is when we architect our system around the desired management reporting structure. Our system will have no clear domain boundaries and any change will require a lot of multi-team coordination, but at least we made HR’s job easier. Conway be damned.
BDD
Bourbon Driven Development is the process we can use when our quality gates are so robust that we can confidently code while enjoying a nice, aged Kentucky bourbon neat. This should always be the goal.
Written on September 10, 2021 by Bryan Finster.
Originally published on Medium