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.

  • This site is powered with the magic of space age email to send my best posts to you each month. No hassle, no spam, no fuss. (privacy policy enforced by my Rotweiller)

You Will Like These:

479 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

    Reply
    • 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.

      Reply
  2. 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

    Reply
  3. Suroor Wijdan |

    That’s such true piece of article. HDD – Hackers driven development!

    Reply
  4. clarissah |

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

    Reply
    • 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

      Reply
    • JBStonehenge |

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

      Reply
  5. 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.

    Reply
  6. 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.

    Reply
    • Alex Hagan |

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

      Reply
  7. 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.

    Reply
  8. 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.”

    Reply
  9. 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

    Reply
  10. Bernardo |

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

    Reply
  11. 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.

    Reply
  12. 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.

    Reply
  13. 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….

    Reply
  14. 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.

    Reply
  15. Java Programmer |

    Believe it or not but half of software development is done by asshole.

    Reply
  16. Lareina Mccarty |

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

    Reply
  17. 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.

    Reply
  18. 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.

    Reply
  19. 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

    Reply
  20. 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.

    Reply
  21. Amine |

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

    Reply
  22. 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.

    Reply
  23. 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.

    Reply
  24. 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…

    Reply
  25. Farhan |

    So true

    Reply
  26. 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.

    Reply
  27. 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.

    Reply
  28. Bryan |

    Pigeon Methodology

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

    Reply
  29. 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.

    Reply
  30. 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

    Reply
  31. Noah |

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

    Reply
  32. 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.”

    Reply
  33. 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.

    Reply
    • 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.

      Reply
  34. 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.

    Reply
  35. 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.

    Reply
  36. 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.

    Reply
  37. 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.

    Reply
  38. 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.

    Reply
  1. [...] development Cover Your Ass Engineering (CYAE)

  2. [...] Berkun has a great post entitled Asshole Driven Development, which expounds upon various software project management styles, including Cognitive Dissonance [...]

  3. [...] } Von Zeit zu Zeit findet man eine Perle in den Archiven einiger Blogs, so den Artikel Ass driven development von Scott Berkun, einem ehemaligen Programmmanager bei Microsoft (Internet Exploder 1.0-5.0, [...]

  4. [...] Scott Berkun: Asshole driven development [...]

  5. [...] How to create a good domain model. Top 10 advices 5 Nontraditional Ways To Improve WordPress SEO Asshole driven development Usability Testing: Don’t Guess, Test Mockito: Java Unit Testing with Mock Objects Google I/O: [...]

  6. [...] of what I call “A**hole Driven Security Teams” tactics.  I adapted the concept from Scott Berkun’s blog post, but the idea is simply this: a security team that is led by one or more individuals exhibiting [...]

  7. [...] don’t let friends act like asshole architects.  The respect you save may be your own. Share this Nugget of [...]

  8. [...] 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. [...]

  9. [...] 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. [...]

  10. [...] I did find, however, was a wonderful blog post from a few years ago with the excellent title “Asshole Driven Development”, in which Scott Berkun has collected a wide variety of development and project management [...]

  11. [...] to do with this post, though, was to direct you to two web pages: the Waterfall Manifesto and Asshole Driven Development. There’s enough painfully true stuff there to, well, be [...]

  12. [...] current frustrations with work to a friend who happens to be a software developer he shared with me this link to a blog posting titled Asshole Driven Development by Scott Berkun. The article provided five [...]

  13. [...] 1. You believe in asshole driven development [...]

  14. [...] Asshole driven development (Now with 285 comments) Tweet [...]

  15. [...] Zeit zu Zeit findet man eine Perle in den Archiven einiger Blogs, so den Artikel Asshole driven development von Scott Berkun, einem ehemaligen Programmmanager bei Microsoft (Internet Exploder 1.0-5.0, [...]

  16. [...] Berkum wrote an interesting essay; or so I thought because it struck a cord. This article was written in 2007 and before I realized that there was a followup to it in 2008; I had already [...]

  17. […] about you? Are you using some the most common development methodologies from list Asshole driven development? The most common is ADHOC, a nice name for unoroganized […]

  18. […] I discovered Planning Poker, and again was amazed by how it can solve Asshole Driven Development issues (me being the asshole most of the time). I immediately decided to apply it with the team I […]

  19. […] Test Driven Development (whereby acceptance tests drive the unit tests) and less serious ones like Asshole Driven Development (whereby the biggest jerk makes all the big decisions) and to these, I’d like to add my own: […]

Leave a Reply