Asshole-driven development
[Since this was originally posted commenters have added 100+ addition methods – see the comments below. There’s more commentary on reddit]
The software industry might be the world’s greatest breeding ground for new systems of management. From Agile, to Extreme Programming , to Test Driven Development (TDD), the acronyms and frameworks keep piling up. Why?
Some say it’s immaturity: that software is still a young industry and all the change is the path to some true fundamentals. Others say it’s because software people like making things up and can’t help themselves. Well I say this: if we’re going to have dozens of models we may as well have some that are honest, however cynical, to what’s really going on much of the time. There is a happy list of these I’m sure, but this is the cynical one.
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.
I’m sure you’ve seen other unspoken methods at work – what are they?
Please add to the over 200 reader suggested methods in the comments.
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!!!!
PPD – Ping Pong Development
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.
How about JLMD – Jesus Loves Me Development [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.
I sometimes think I work for a company that uses
ADCDCYADBDGMPM – Asshole Driver Cognitive Dissonance Cover Your Ass Development By Denial Get Me Promoted Methodology
NST Development – Next Shiny Thing Development. When your development focus changes every time your boss comes back from a tech conference.
Obviously Scott Berkun knows too much. Black helicopters should be dispatched to his location immediately.
TNF – Toilet Never Flushes development – 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.
TunnelRat – disagree about waterfall being a red flag – usually people don’t build skyscrapers “on spec.”
WAILDD – Worry About It Later Driven Development – we all have done this at some time! It usually applies to issues of performance and scaling…
VWRAH – Visions Without Resources Are Hallucinations, not only a development caveat but also a universal project truth.
Thank you guys for writing these posts. They remind me of what it was like to work at previous companies. I have managed to find an organization essentially free of these development paradigms. The developers call the shots here and we do our best not hire assholes or incompetents. The only thing that gets people promoted here is solid work being recognized by peers. I suppose we subscribe to Sanity Driven Development (SDD.)
The only one I see missing (after all the add-on posts) is “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!)
Hahahahaha!!! Very fun! :) I just posted an entry in my blog about ADD: http://gc.blog.br/2007/06/21/asshole-driven-development/
Besides that, congratulations for you book (Myths of Innovation). I did not read it (yet) but some friends of mine found it fantastic!
Best regards,
Guilherme
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.
how about Everyone is an Architect Development, or 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).
I’ve just finished a big C++ project at a (somewhat) famous stock exchange (consultant, programmer) and I’m quite amazed over the fact that…I recognize almost everything you guys/girls say about projects. This seems to be a global problem, same thing all over the world.
Regards
This happens everywhere. The real problem is people lacking maturity to solve problems. Bad kid grows up, gets authority, remains bad kid that can inflict more harm become Middle managers, create the distortion field and thrive in it like a demon from hell or become sales. Same thing. Remember, you’re on the team and others may see you the same way.
How about *Buzzword Driven Development*. 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 — 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!”
IDD (Inertia Driven Development) — 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.
Related Methodology: GOBD (Good Ole Boys Development) — 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.
or
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.
This is something I wish I had read before I left university
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.
DDIH (Don’t Do It Here) Development – 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.
I believe, you should name your methodologies and introduce a certificate for it . Unfortunately it will be the most popular certified methodology ever
Thanks for that :)
CVDD : CV Driven Development – 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).
very funny! i submit Cross Your Fingers Development, 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.
OBD: One Badass Development – 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. :)
Thanks for the post and the comments. I forwarded them to our CTO for review. We have a lot of ADDs!
IADD – “It’s Almost Done” Development. 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.
An example of this is when you as a project manager/lead developer are assigned the task of distributing projects and tasks to other developers in your team – without staff removal or replacement powers which rests with your boss.
You assign a project to a developer he says “yeah sure…” When asked about progress when the deadline is visible from your timeline horizon, the said developer would reply “it’s ‘Almost Done'”.
As development days progress, you’d receive youtube links and other interesting and funny links from the said developer.
At deadline, you ask him about the project he replies “It’s Almost Done – it will be there next week.”.
You extend the deadline. One week later when the deadline comes, you ask him about it and he says “It’s ‘Almost Done'”.
You ask to see what he has so far and that he release the parts that he’s done, and he says “yeah sure… ” when you ask him about the release, he says “It’s ‘Almost Done'”.
This goes on in a perpetual loop which ends when the condition of the developer leaving equates to the boolean value of true.
When you go to pick up the project to hand it off to some other poor schmuck and review it, you find that there was nothing done at all.
I worked on a project almost 10 years ago that seemed to match your description of DBD.
I occasionally worked for one of the managers at the company. I was working on some other projects at the time for someone higher up. This manager misunderstood the situation, because her boss (same as my boss) told her something that wasn’t true. She thought I was working on something that was critical path to her project, when in fact I was only tasked with coming up with the method for doing it (ie. experimenting with different approaches to see which one worked). She thought I was going to write all of the modules for her project that would fill in this critical piece–I was never told this. I find out 3 days before her project is supposed to be delivered that this piece hasn’t even been started yet, because nobody was directly tasked with it! And it was me who figured this out! I was brought in to an emergency meeting to try to save the project. I was disgusted already. Out of the goodness of my heart I volunteered to “save the day”. The project was delayed by a week, I was put in charge of a team to work on getting the critical piece done ASAP, and we got it done. I think it was a matter of miscommunication, plus the fact that this manager obviously wasn’t very good, because she wasn’t on top of this. It didn’t matter. That experience led to my decision to quit my job several months later. I have no tolerance for “amateur hour”.
BTW, nothing against female managers. I didn’t mean this as a slam against a certain gender. The female manager on this project had her deficiencies, but the manager who really screwed everything up, her boss and mine, was a guy.
Jellybob:
BDD is how every project I’ve worked on has worked. The budget almost never fits the size and scope of the project. Personally I think this is because of the common practice of fixed bidding for projects, which ends up forcing the development team to use the Waterfall Model. You have to estimate how much the project is going to cost before you’ve even written a line of code. Totally unrealistic approach, but that’s par for the course.
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?
Wow a very insightful essay on the ‘science’ of software delivery. Dugg!
In my organization we firmly believe in DDD (Defect Driven Development). Its a smorgasboard of most of the above mentioned ‘principles’, primarily NKWYWUYSI, NMP, NADD etc.
We start off with ODS, just do something insubstantial in the ridiculous timeframe given to us, and hand it over to the testing team (Faith-based development too does come in here!). Then just open the floodgates and let the defects pour in. Obviously the defects are not mundane – ‘some one-in-a-gazillion failing condition’, these are serious lack of functionality!! Then you end up getting these defects solved by the same development team that delivered the incomplete product in the 1st place!
Magic!
This is a very impressive methodology in that:
1.) Progress of the development is always quantifiable, as in (no of defects solved) / (total no of raised defects) * 100
2.) When its the developers’ appraisal time, the defect tracking system gives invaluable statistics like no of defects solved, total time spent on defects etc.
3.) The equation is simple. Development=easy,self-paced,early evenings, weekends off.
Defects=late nights, feverish pace, client pressure, weekends!
Indepth inhouse research has revealed that the proletarians are much more efficient when numbed by sleep deprivation. This making DDD the most successful s/w methodology in the history of mankind! :-D
Don’t worry, we can always refactor later (DWWCARL) – forget about laying out any kind of design or architecture, just jump in and code! We can easily refactor later… we’ll want to when The Next New Thing comes out anyway. I hear that Ruby on Maglev is going to revolutionize the way we work! Remember, Value Working Code Above Documentation. When you’ve got over a million lines of code with no documentation, throw a party & celebrate. It’s easy to teach new people the system… just pair for 2 years.
All Chiefs No Indians (ACNI) – The inherent belief that you can manage your way to a software product without having anyone to actually build it.
Where to begin with this list? Every company i’ve seen has 90% of this covered.
I suspect that the reason we have such crappy management in software is that people are attempting to shoehorn a creative process into an engineering discipline. It just doesn’t fit and makes everyone miserable.
http://crankyslacker.blogspot.com/
Client Wants It Anyway(CWI) – no matter how inane or unusable, just because the marketing teams wants it then it has to be in there… usually an over-budget, non-spec’ed that will never be paid for – this way of developing is usually propogated by weak and ham-fisted Project Managers.
Best blog post ever.
This is great it sums up a great deal of what I have seen during my 40+ years in this business.
One of the oldest Add Resources to a Late Project (ARLP). This was made famous by Fred Brooks in his classic book – The Mythical Man-Month. See http://en.wikipedia.org/wiki/The_Mythical_Man-Month
Similar is Any Resource Will Do (ARWD), utilized in many large shops to keep things moving. Planning is done based on the “average developer”. Staff is moved from one assignment to another, just before they have gained enough knowledge to make a difference.
Those of us in Academia can’t forget:
TDD – Tenure Driven Development
and
ISIFD – “I Swear It’s Feasible Development”
Lazy Developer-Driven Development (LDDD) This is where developers site around on Friday afternoons reading blogs like this and laughing about managers when they should be focused on executing their 10 number one priorities.
Resume Padding Development (RPD) – Where technologies are used to gain experience and add them to one’s resume, even though it is not a good fit for the project. Related to Buzzword Driven Development and Must Use Specific Technology Development.
CRAP = Completely Redundant Application Process – This is where you create the same application someone in your company, division, department, or cubicle has already created. But you either A) want to write your own, or B) had no idea someone else had done it.
TURD – Temporarily Under Repair Development. The development engineers do when the site is down, and the sorry page is up.
Show Me A Rock Driven Development (SMARDD) – (Typically used in conjunction with ADD,et.al.) Prevalent in projects with no clear requirements, vision, process or adult supervision. When developers ask the manager/customer/whoever_is_paying_the_bills_this_week what they want, the response is “I don’t know, but I’ll know it when I see it,” which when translated into non-idiot speak reads “show me a rock.” As code and features are completed they are presented to the manager/customer/whoever_is_paying_bills_this_week the response is “That’s not quite what I had in mind, try again.” Translation again –> “Not that rock. Show me another rock.”
After being denied several times, developers finally wise up and start bringing a whole bucket of different “rocks” to each demo, resulting in vast amounts of duplicated effort that is destined to never be used.
How about Responsible With No Authority Development(RWNAD) where you are responsible for making sure things work but you have absolutely no authority over servers, deploys, logs, etc. May be related to one of the many methodologies mentioned above and very closely related to “Separation Of Responsibilities” (SOR) coming out of SOX.
Technology Du Jour Development (TDJD) – Haven’t scanned all of the above, so this one might well be listed already. The practice of seeing that some new technology is currently hot, and deciding your next project will be built around it. Never mind that the technology isn’t mature, your people don’t know it, it doesn’t fit with any of your existing projects, and there’s a good chance it doesn’t even fit THIS project.
Love the list but one is missing. The antithesis OSD is “That’s in Phase Two” Development (TIP2) where critical functionality is left out of the first phase because the requirements phase is over. These typically surface as follows:
Programmer: “Orders are not being posted to A/R.”
Manager: “It’s not in the functional requirements so, that’s in Phase Two”
You forgot about PMW: Project Management Warlordism where project managers act like turf-centric warlords …
Far out, there’s a lot of anger here about development methodologies, but some great new ones being developed here. I look forward to reading them in the next book.
nice to know we’re not alone in the wasteland…how about UDNALD (U Don’t Need A Life Development)? You should sacrifice more nights & weekends to get this project right because you love believe in this job more than anything, right? Right…
That’s All I Know Driven Development When the decision maker only (sort of) knows how to work in a tool or environment and hacks or “abstracts” all parts of the system into that environment. Boy have I been suffering from that one!!!!!
Not My Job Development (NMJD) – As everything you have to do is not always in the scope of your skillness or the job you applied for, the NMJD methodology allows you to go fishing earlier in the week throwing your tasks to your next colleague. The main problem is when everybody in the company apply this methodology.
Personal Identity Driven Decisioning (PIDD) – people who seek positions and make decisions pursuing a fantasy self image, when in actuality they woefully lack the skill to perform their job. PIDD endemic to middle management from CTO down to PM, inclusively.
How about Developer Dysfunction Development (Trip D’s) – Hi I went to ubertechnical school and create a program that will write in cursive but I don’t have a clue on how to interact with people or even understand why corporate organizations exist but I’m going to tell you why I have an opinion about how the complex organizational procedures being instantiated in this program are wrong!
Or how about Developer Myopia Development (DMD) – I really like this thing I can make the technology do because I figured it four years ago and I’ve been dying to implement it somewhere and even though this is the wrong solution for the problem.
How about Continual Requirements Analysis Paralysis – Methodology, otherwise known as CRAP-M. I spent a number of years working in the DOD sector and was painfully, intimately involved with that.