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.

499 Responses to “Asshole driven development”

  1. 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
  2. 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
  3. 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
  4. 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
  5. 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

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

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

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

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

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

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

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

    Reply
  12. Olaf Radicke

    Overengineering Driven Development (ODD)

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

    Reply
  13. Jordan Georgiev

    [JAFA] Just A Few Alterations Development – consists of a team of at least 100 software engineers spending at least 5 years on fixing up, bootstrapping and building around a quick piece of software made by 5 people for 6 months.

    Reply
  14. Domas

    [SUF] Soviet Union Factory methodology – documentation is not existant, one dev doesn’t know what other one is doing or what an overall project should do. Given small and specific tasks they stumble in the code blindly. Communication is kept to zero. Code is full of methods who perform exact same function. Patterns are either non existent or there’s as much of them as there’s developers rendering any effort to keep structure clean useless. Management thinks project is too big to fail

    Reply

Pingbacks

Leave a Reply

* Required