A software development methodology or system development methodology in software engineering is a framework that is used to structure, plan, and control the process of developing an information system. On 19 June 2007 Scott Berkun wrote a blog post titled Asshole Driven development. It struck a chord with developers world wide and everyone chipped in with various terminologies originating out of their own experience. I enjoyed reading it and purely from an archival purpose I have collected them all and putting it in here. All the content in this post are taken from the original post/comments titled Asshole Driven development by Scott Berkun.

Asshole Driven development (ADD) – Any team where the biggest jerk makes all the big decisions is asshole driven development. All wisdom, logic or process goes out the window when Mr. Asshole is in the room, doing whatever idiotic, selfish thing he thinks is best. There may rules and processes, but Mr. A breaks them and people follow anyway.

Cognitive Dissonance development (CDD) – In any organization where there are two or more divergent beliefs on how software should be made. The tension between those beliefs, as it’s fought out in various meetings and individual decisions by players on both sides, defines the project more than any individual belief itself.

Cover Your Ass Engineering (CYAE) – The driving force behind most individual efforts is to make sure than when the shit hits the fan, they are not to blame.

Development By Denial (DBD) – Everybody pretends there is a method for what’s being done, and that things are going ok, when in reality, things are a mess and the process is on the floor. The worse things get, the more people depend on their denial of what’s really happening, or their isolation in their own small part of the project, to survive.

Get Me Promoted Methodology (GMPM) – People write code and design things to increase their visibility, satisfy their boss’s whims, and accelerate their path to a raise or the corner office no matter how far outside of stated goals their efforts go. This includes allowing disasters to happen so people can be heroes, writing hacks that look great in the short term but crumble after the individual has moved on, and focusing more on the surface of work than its value.

Low Hanging Fruit Development (LHFD)

Path of Least Resistance Architecture (PLRA)

Dead Man Walking development (DMWD). This approach is frequently used for projects at companies who are in the process of outsourcing development jobs. Some of it’s highlights involve training your eventual replacement and pretending that they don’t suck so as to be a “team player”.

Mao Model of Management (MMM ). Thats where you’re never told what you should be doing, you’re only told what you shouldn’t be doing. Generally you are told what you shouldn’t be doing only after you’ve started doing it.

Development By Crisis (DBC) or Management By Crisis (MBC): Everything is a Crisis. Every task, you have to “Drop everything” and work all night long! Woe to the developer that mentions that the user acceptance testing doesn’t even begin for another 2 months… Everything is a disaster.

Can’t change won’t change development (CCWCD). This is where any new improved development technique / method / idea is rejected because we can’t retrofit it into ALL of our existing code and previous releases.

Without Half A Clue Development – pronounced “whacked” (WHACD)

Whack-A-Mole Management (WAMM). where management feels compelled to beat down any heads rising above the rest.

Too many chiefs Development (TMCD), not enough Indians. When you have 6 bosses each trying to take the project in different directions. At least one boss wants you to figure out why his laptop keeps locking up and another wants you to come to his house to setup the interweb. The others require you to attend at least one 3 hour long conference call with them per week.

The process development(TPD). When the process of the project becomes more important than the project itself. No work can be done without a TPS report. See Sigma Six for further details.

It’s Tuesday development(ITD). Feature freeze and requirement specifications? Hell no. Today we are changing out the requirement so much that we are effectively working on a different project. Why? Because it’s Tuesday.

“You will be gone, I’ll be gone” so who cares.(YBG IBG)

Document Driven Development (DDD) – copious amounts of inaccurate, verbose and unnecessary documentation are prepared and maintained as if they somehow embody everything that needs to be done in the software. A developer must even implement typos in the user interface if that is how the document is specified. Code that deviates from the specification is incorrect even if it is how the product is intended to behave. No changes to code are allowed unless the document is revised, reviewed, approved, submitted, published and re-distributed. And don’t forget to increment that version number!!!!

Ping Pong Development(PPD)
A development methodology where you enlist a minimum of two stakeholders with mutually exclusive requirements and visions and then have them directly harass the developer constantly. Works best if the groups wait until just before a major revision is complete before they explode and get pissed at you for doing what asshole #1 wanted. Also related would be Eternal PPD or EPPD, where the ping pong game is neverending because the group of stakeholders will never agree on any feature that the software should have, but no one wants to admit defeat and cancel the project either.

Jesus Loves Me Development(JLMD) [or other deity, but every good acronym has a J in it])? This method is employed when the project is small enough or the timetable short enough so that thorough requirements are never completed. Rather only a vague, general description of functionality is provided. The only way to motivate yourself to code the project requires a firm belief that God will intervene, miraculously making what you produce align with what the customer wants.

Asshole Driver Cognitive Dissonance Cover Your Ass Development By Denial Get Me Promoted Methodology(ADCDCYADBDGMPM)

Next Shiny Thing Development(NSTD). When your development focus changes every time your boss comes back from a tech conference.

Toilet Never Flushes development(TNF) – the analogy is the water goes round and round and up and down but the goods never reach their intended destination. This is typically a result of Agile-like where management and prioritization of functionality typically illustrates a big picture design oversight that requires major refactoring – so much so that most developers on the project spend 3/4 of their day fixing the present build because of development blinders trying to bludgeon in significant infrastructure changes.

Worry About It Later Driven Development(WAILDD) – we all have done this at some time! It usually applies to issues of performance and scaling…

Visions Without Resources Are Hallucinations(VWRAH), not only a development caveat but also a universal project truth.

Must Use Specific Technology Development(MUSTP). I don’t know how many projects I’ve been on where someone (even sometimes a reasonably smart and technically savvy engineer) dictates that the solution must use a specific technology (EJBs, XML, OODBMS, OSI protocol, .NET, Smalltalk, etc.) “because it’s the future”. Of course, you end up shoe-horning the technology into places where it clearly doesn’t fit – or it’s too immature to use successfully and eventually everyone looks back and says: “why the hell did we do that?” (Maybe we should call this “The Square Peg-Big Hammer” methodology?… It’ll fit into the round hole if you hit it hard enough!)

Blame it on the Developer (BD): When the application fails due to oversights on the part of the project manager, the developer is blamed. The developer may have warned you that the application wasn’t ready for release, that components from other groups weren’t ready and tested, but it was released anyway. This is often a resume building moment for the developer.

Everyone is an Architect Development(EAD). something i noticed during the dot.com era was that junior engineer anymore. everyone was a senior engineer or an architect. insane i tell ya … bloody insane. for this reason alone i despise job titles to this very day.

Partial Extreme Development (PED) – that’s where developers take only the parts of extreme development process that they like (short iterations, pair partnering) and ditch the rest (documentation, unit testing).

Buzzword Driven Development(BWDD). A few months ago it was SOA, now it is DDD. Whatever is best for the project does not count; what counts is whatever is hot right now.

Technology Driven Development(TDD)— asks what technology we know how to use, then designs a system around it. “Need a backend for your e-commerce site? Sure, we can do that with Foxpro!”

Inertia Driven Development (IDD) — Executives made some money to off the last major product innovation ten years ago, but not enough to retire. The organization becomes so top heavy that anything innovative is blocked so as to not disturb their road to retirement.

Good Ole Boys Development (GOBD) — A group of executives operate more like a fraternity than a software development organization. Nothing ever gets done, but there’s always some reward being handed out.

Everything is High Priority (EHP) – Management comes and tell you that something is required ASAP and next day something else is required ASAP – in the end nothing gets done!

No Time For Design and Usability But Plenty For Gold Plating – This is when Development apparently has no time to properly code for and implement the design as delivered by the design team; but when the product is available, miraculously all sorts of additional cool features and flashy items manage to make it into the product.

Keep Hacking the Hacks – This is when Development or the company keeps driving forward with no thought given to the quality or condition to existing code, etc. They continue piling hacks upon hacks and hacking the hacks to get product out the door, then wonder why things break, or why it takes so long to get things working, or why no one can come in and pick right up, etc.

No Customer Left Behind Development (NCLBD) where management insists that every feature ever requested by any current customer, no matter how trivial or esoteric, must be included in the next version.

Don’t Do It Here Development(DDIH)– This occurs when management has a low opinion of its own staff engineers, and so insists that all significant projects be done by outside consultants while staff is confined to maintaining the mess created by the last team of consultants and people who’ve already moved on.

CV Driven Development(CVDD) – A variant of NDD – Nerd Driven Development and Must Use Specific Technology Development (MUSTP), places the coolness/shininess of the chosen methodology/technology as seen on the CV of the architect above all other requirements. Project collapses as soon as it is realized the method doesn’t work, the architect leaves or the next new technology arrives (refactoring time).

Cross Your Fingers Development(CYFD), where allotted development time is so short there’s no time for tests, and so at release time you just cross your fingers and hope it works.

One Badass Development(OBD) – Near deadline time everyone winds up going to the one badass of the company for help. In the end, the badass finds that everything that everyone else has done is crap and winds up doing the entire project by himself in a few days without sleep. You might want to hire a few of badasses, because they’ll often quit when learning that this development process is in place.

Almost Just In Time Development (AJITD) – When you know you don’t have a snowballs chance in hell of completing the work on time, but you rough it out enough to get into QA and then finish the features as blocker bugs. 🙂

It’s Almost Done Development(IADD). This Development methodology is common in small to medium development houses where certain procedures and policies are not set entirely and you are assigned a team with one or more “dead weight” developers.

Teacher’s Pet Driven Development (TPDD) – when one developer is a favorite of a manager and thus bypasses all logic, design and reasoning in favor of the pet’s whims.

Lack of Decision Development (LADD) – no one wants to make a decision about anything so the product gets implemented by the slimiest developer while the others puzzle helplessly.

FUD Development (FUDD) – implementing the feature the right way is huge and scary and bad in every way imaginable, therefore this other way is good and we started working on it while you were at lunch.

Idiot Savant Driven Development (ISDD) – the one developer who knows one language and one way to hack bludgeons software into existence by sheer force of will and time, leaving management to talk about “great productivity” and “working the long hours necessary”. Then it explodes and no one knows where to point the finger.

I Was an Expert Once Syndrome (IWEOS) – senior-level people “contributing” because of their years of “expertise” that grant them the inalienable right to shit on every discussion, whine about everything out of their comfort zone and squeeze in every last “favorite” feature into the final product.

Angst Ridden Development (ARD) – being alone on a mountaintop fighting back the animals, the invalids, the fear mongerers, the savants and the tired old hags with a single trusty sword made of quality and rationality.

Can’t Really Afford Pro’s (CRAP) – Using interns on crucial parts of important projects.

Patent Driven Development (PDD), also known as Lawyer Driven Development (LDD) – don´t need to develop selling Products, just produce enough Patents to sue.

Darwinian Development (DD) – where the developer has no idea what he is doing and changes random bits of code until the bug is fixed. The changes made that did not contribute to the “fix” are usually left in, often breaking other parts of the system. You did test the other parts of the system after you made the changes? Didn’t you?

Fear Driven Development (FDD) – Where the work is done not my motivation but by fear