Asshole driven development

[Since this was originally posted commenters have added 100+ addition methods – see the comments below]

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.

493 Responses to “Asshole driven development”

  1. Umair

    NDAD [No Developers Allowed in Decisions] Methodology. Where developers of all kind are strictly forbidden from the entire project all details, to back end design, to deadlines, to review meetings, to what ever the Software Life Cycle has because the middle and top management know exactly what they want, how it should be done, and how long it will take. this methodology as most has the ADD man on top but is non-technical management who read an article some where some place

    • tomcp

      DDD Developer-driven development

      Main properties : strong case of NIH syndrome. Everything gets rewritten. Mysql ? I can do that better ! Methodology is judged as way, way more important than getting anything working. There’s way more unit test code than code (like 5x more). Code is so slow you could be forgiven to wrongly conclude after 30 minutes it crashed. Code does not actually work, the program segfaults or excepts before getting to the second line of the main function (which is never run in unit tests). But there’s hundreds or thousands of unit tests all of them never failed once.

      And of course when you write a system test and force it on the developer it’s “unfair”. The system test fails when it runs too slow (btw: that’s by design, and yes it does say that it succeeded, except for time limit), it then becomes flaky when they’re close to acceptable speed. These are apparently bad things, according to developers.

      And of course it regularly finds faults in module interaction that the unit tests never catch. But when it does it’s hard to figure out what went wrong, and where exactly. Again this is considered a bad thing, in the sense that not knowing about these failures and having paying customers discover them the hard way would be far preferable, apparently.

      Oh and God forbid you come up with a system test that actually starts up external programs and actually interacts with them like the production system will. “That’s mysql screwing up”. “That’s asterisk refusing to work”. I don’t think so, but what point are you making ? Even if you’re right, which seems unlikely, it’s still your problem to fix. “That bug only occured because the network dropped a packet”. My response : “That’s fantastic ! Make your system less brittle”. “That system didn’t behave as documented”. Isn’t it great that we found that ? Apparently not.

      • iServed

        Christ, Tom, do you work where I work?

  2. clarissah

    CRAUG development
    Change Requirements As You Go Development – when months spent planning and designing the product and at each turn the requirements change.

    • Ronney Coolman

      I totally hate this one. I’ve been through such for only a couple of months, but it proved to be a good sift for friends and ass-lickers. I banned all “were-friends” then since I took several knives in my back by them

    • JBStonehenge

      moving target development
      It is well known as moving target development where the yetserday’s code hack makes no longer sense.

      • iServed

        Speaking of Agile, let me add …

        LSD – Lip Service Development: The project team pays lip service to the framework du jour and repeats old patterns of whatever made up methodology they use.

  3. golfadas

    UDD: University Driven Development – When you have a project to code but have no idea how to do it, eventually you find out how three nights before the deliver how to get it done so you do some soup code that passes a couple of tests OR you do beautiful code that doesn’t do shit

  4. Lenary

    Channel Tunnel Driven Development: 2 halves of the team work on the same problem starting at opposite ends, and hoping that they’ll meet in the middle. They won’t.

  5. David Coleman

    Asshole Driven House Of Cards [ADHOC] Development It describes 99 % of software on the market these days and is exactly as bad as it sounds.

    • Alex Hagan

      Love it. Not only is it true, it has an appropriate and catchy anagram. You should start a consultancy!

  6. me

    What about IDD; Idiot Driven Development.

    This development scheme is often characterized by a client, who hasn’t the slightest ripping clue what they ACTUALLY want/need, driving the development process. The client is often an individual who has devised a singular idea for a product, yet has no experience of any kind with actual product development/creation. Suggestions are often ignored. The input of the programming team is a laughingstock. Process is ignored. Deadlines are missed. The marketing team not only sells things, but attempts to demo things before the development team has ever even heard of them.

    The entire process is characterized by everybody running around, with their pants on fire, like a chicken with its head cut off, and nobody knows what is going on, EVER. This development pattern incorporates most of the known ADD patterns currently identified, but it often much, much worse, particularly because it’s all spearheaded by incompetent morons who probably print instructions on how to unlock a door with a key; i.e. idiots. Hence, Idiot Driven Development.

  7. Manoj R.

    TLDD :- That’s legacy driver developement.
    “That code, process, design is legacy and working till now. We should not touch it. If any error occurs let’s patch it.”

  8. Harris

    DKS Development – Don’t know shit Development

    A mode of development where nobody knows shit about the project, but they still do it. It is a derivative of Channel Tunnel Driven Development

  9. Bernardo

    JSB – Job Security Development – Make the code as hard to understand as possible, so that they won’t be able to replace you.

  10. GaZ

    TPSFPB – Ten Pounds of Shit in a Five Pound Bag Development.

    A method of development using non-scalable architecture to support an infinitely scaled application.

  11. OWBO

    EESAIDIR – Everyone Else Sucks And I Do It Right Development

    I believe this to be the method of development every programmer uses regardless of whatever sub-method they say they are using.

  12. Sam

    JGIDD – Just get it done development.

    When you have no idea what the hell you are suppose to code and manager asks u to make a demo for the client and do whatever it takes to complete it in one night. In these scenarios u don’t care how bad u r coding. How u r placing the standards, best coding practices, design patterns and even common sense under your own feet….

  13. Scott Warren

    Multi-brain Development – Where there are multiple bosses and while they agree in the meetings they go off in their own direction when away from each other.

  14. Lareina Mccarty

    discussions of key database and XML principles you need to know in order to be effective with ASP.NET.

  15. IshmaelHolt

    I like the formatting commands–I was just selecting text and use the Tab key when indenting didn’t come out the way I wanted.

  16. DuncanThom

    ASP.NET emerged as a framework that gives plentiful opportunities to build fully-functional websites, web-based apps or XML services. As an advent by Microsoft it carries out mammoth .Net support & other boundless core features.

  17. David

    CTRL+Z Development*: A derivative of “Change Requirements As You Go Development”, when not only the requirement change, but also you have to undo one step for each two steps you do. A typical sentence you hear when applying this methodology is “I’m not sure if that’s what I want, but start doing it and we’ll see if it is or not.”.
    * The name of the methodology is idea of a colleague xd

  18. Tom3d

    Travel Driven Development

    Find a outsourcing software partner on Hawaii or Mumbai only to give management a possibility for important discussions outside of office, including evening programs and weekend..

    Awesome article btw.

  19. Amine

    GIPTSD – Give the Interesting Project to the Sexiest Developer: when the PM gives the interesting project to the Sexiest developer in the team.

  20. Timon Nielsen

    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.

  21. darius

    *Promoted Demo Development*

    The project manager asks a developer to develop a quick and dirty demo for a client, only to have the manager ask for more and more features, and after a few months of such iterations, the developer realizes he is actually developing the final product.

  22. Minui

    CAAR “Client are always right”

    Client want something, no challenge, no negociations, not even reflexion on the project, just obey because he or she pays or have its company name in DJ or NASDAQ…

  23. Adam Ralph

    I just *have* to add this because I’m always referring to it:

    Golf Driven Development

    E.g. unfathomable vendor lock-ins, arbitrary promises to deliver project X on deadline Y, using SharePoint, using IBM, using McAfee, etc. etc.

    These kinds of decisions can only possibly happen in one place.

    The golf course.

  24. thilko

    GDD – Google Driven Development: Knows nothing at all and uses Google for important design decision rather developing in context of the domain and the team.

  25. Bryan

    Pigeon Methodology

    Boss flies in, shits all over everything, and flies away

  26. Avathar

    CPDD – Copy-Paste Driven Development:

    Where all features are a remix of older projects, stackoverflow answers, stolen CSS and just-like-the-demo JS gimmicks. When a new feature is asked, the team goes crazy searching in google instead of sit down and do their own thinking. Very popular among some college students.

  27. Develop-mental

    Scat Driven Development (SDD) – Architecture craps it out in the form of frameworks and the developers try to sculpt that turd into a product. They just end up making a big shitty mess

  28. Noah

    DDD = Developer Driven Development. Developer just do what they want and ignore PMs. (Budgets/Scope/etc.)

  29. Mark Tomlinson

    This is one of the best, longest-running threads in our industry. 3 years+!!!

    My contribution to the naming: Bong Driven Development

    “Wait, what? Did you see that!? Man, wow.”

  30. YodaOne

    Apparently you have to be an asshole (preferably a sadistic, sociopathic one) to develop at Microsoft. I’m now convinced that they wake up beaming every morning, thrilled that while they slept, millions of their customers around the globe shook angry fists at their products. They are happiest when they manufacture frustration for others, so clearly they are extremely happy assholes.

    • David

      Great post! I was waiting for someone to mention Micro$oft. My words exactly. And I’m one of those customers shaking my fist at Micro$oft almost every day.

  31. Will Hix

    Design By Politics. Especially popular in the government. The Obamacare website fiasco may be a good example of this syndrome. Rather designing the most effective, most efficient system, you design around and through a maze of existing crapware and bureaucratic edicts to produce something that will at least do part of what you were supposed to do and will meet whatever arbitrary deployment dates the political appointees have pulled out of their asses.

    Optimistically this might be referred to as the art of the possible. You end up with a functional, but flawed product and you know it could have been a lot better, but you have a “better than nothing” solution at the end.

    And people who were not aware of any of the horrors of the sausage-making process then criticize it later, like you were too stupid to see the train coming down the tracks, when you were the guy screaming that the train was coming around the curve and people ignored the warnings.

    Looking forward to retirement and being able to be a spectator to the train wrecks rather a casualty.

  32. Thad Bryson

    God Only Development – Where only gods will do. Any problems or bugs will not be tolerated. Doesn’t matter how many users use the software, on how many different systems, what other software will be used with it at a later date, or anything else that may come up. If There are any problems it’s your fault and you will be in trouble.

  33. Ghost

    I never saw any of the infamous:
    1. DNFL (Drunk Now – Fix Later) approach.
    2. HDS (Happy Debugging Suckers) technique.
    3. OGCJM (Only God Can Judge Me) development.

    and my personal favorite
    4. LSIYCKUTTMDHE (Let’s See If You Can Keep Up This Time My Dear Hardware Engineers) religion.

  34. e-commerce

    DRTBD : Don’t Rock The Boat Development.

    Satisfies all those senior developers that are looking forward to retirement and don’t want to develop on anything that was not tried and proved during the 90’s, the decade in which their latest mindset update took place.

  35. Matthias Johnson

    I humbly submit the following:

    “color driven design”, where the code doesn’t matter, as long as it’t he right shade of blue. If you work on the backend you don’t have restrictions, since it doesn’t matter.

    “accent based engineering”, where the guy with the German accent clearly has the greatest engineering skills.

    “half cost procurement strategy”, where it’s great as long as we can do it for half the cost.

  36. Yoda B Sith

    Microsoft developers and/or their leaders, are one or both of the following.

    – fucking sociopaths who delight in the frustration of others
    – fucking incompetent

  37. Since 1974

    EDD – Error Driven Development. Cubicle dwellers are constantly putting out fires, chasing bugs, fixing bugs, debugging, patching bad code, breaking data type interfaces, all because of short-sighted managers who love golf more than software quality. Combined with silly rules like “be here by 8am” regardless of 60 hour weeks and saturdays/sundays. EDD mimicks natural control systems found in nature.

    • Adrienne

      Throw It At The Wall Development (TIATWD).

      Satisfies the CEO who suffers from true ADD (Attention Deficit Disorder) and keeps shareholders confident that the company is releasing one great feature after another. A key to successful TIATWD is that that the company cannot be bothered to observe what happens to the wall because it is too busy slinging the next pile.

  38. Cédric

    ISRAEDD ::= IntelliSense R# Alter+Enter Driven Developement

    Press Ctrl+Space choose something and, press Alt+Enter to add reference no matter which layer, choose a method and think “If it is public then it is OK”.

  39. Xasal

    WHD = Work Hours Development

    A development process where developers make things work in dirtiest possible way just to mark their work hours for the bosses that they did something.

  40. Muhammad Adel

    HDD = Hacker driven development

    It is important to do it, no matter how you did it. Any type of constraints, weather from a language, design or methodology is refused. If it is not performing well, through more hardware at it.

    And of course the less lines of code you use the better, specially of you are using a cool feature from your scripting language the does some sort of magic, regardless of the fact that you are the only one who understand this code, and even you will not understand this code when you read it 3 month from the day you wrote it.

  41. Magnusson

    SMDD- Smothering Hen Driven Development
    -An addendum to ADD, where the asshole smothers you by sitting beside you all day like a hen does with her eggs and suggests a plethora of ideas that will render maximum counter-productivity and clobber any progress back to the stone age. This methodology is further supplemented by CTRL+Z Driven Development, when you follow the asshole’s advice but scraps it after spending much time, effort, and personal life once the client finds out you did something outrageously not in the design.

  42. LarryA

    RIPS – Reward Incompetence Punish Success

    In an ADD-driven environment, the most incompetent get rewarded by the more incompetent, for being members of the same ‘Stupid Club’. The successful, competent developers are punished for making the incompetent managers and their little kiss-asses look bad. Their goal is to force the competents out so the incompetents can continue unexposed and unchallenged.

    They follow the AABC rule–‘A’ people hire ‘A’ people while ‘B’ people hire ‘C’ people. Eventually there are only ‘C’ developers being lead by ‘B’ or ‘C’ managers.

  43. Olaf Radicke

    Overengineering Driven Development (ODD)

    Best way to create great Vaporware. The stable Version of ODD 1.0 coming soon!! …Really! …Sure!



  1. […] Asshole driven development 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. […]

  2. […] Asshole driven development Development By Denial (DBD) – Everybody pretends there is a method for whats 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 whats really happening, or their isolation in their own small part of the project, to survive. […]

Leave a Reply

* Required