• Print
  • June 19th, 2007
  • 341 Comments »
  • Management

Asshole driven development

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?

(Update: There are about 60 more in the comments) and there is additional commentary here.

Leave a Comment / What do you think?

Your email is never published nor shared (comments policy).

341 Responses

  • Alex - June 19, 2007 at 11:04 am

  • Maybe this is a variation of CYAE, but what about the Not My Problem (NMP) approach, in which all complex, complicated, expensive, or otherwise troublesome decisions/features/issues are pushed into someone else’s module?


  • Scott - June 19, 2007 at 11:07 am

  • NMP – excellent! Or maybe it should be called Hot Potato, or Musical chairs style development :) I love that both are children’s games, but yet sometimes that’s *exactly* what a bunch of adults are playing at work.


  • Terry Bleizeffer - June 19, 2007 at 11:50 am

  • A good starter list, but you’ve forgotten a biggie — Learned Helplessness Development — in which team members have been beaten down for so long that they assume that no matter what they do, they’ll suffer because of it. It’s the result of frequent and random negative reinforcement combined with infrequent and random positive reinforcement.


  • Process Perfection - June 19, 2007 at 1:25 pm

  • Asshole driven development… I see a lot of all of these methodologies, but at the moment, I would have to say that DBD is ascendant….


  • Brad B - June 19, 2007 at 1:51 pm

  • Not allowed to do development (NADD) – somewhat similar to CYAE. No actual development is tolerated by the development team. Everyone with any technical knowledge at all is at least 3 levels too low on the corporate ladder to be allowed to make even trivial decisions, and any initiative by individuals is a sign developers have too much time on there hands – meaning they are either poorly managed and ignoring whatever it is the bosses boss thinks they do, or they can be laid off. Developers are occasionally fed poorly written specs, not allowed to ask questions, and yelled at for “being late” before they are given the 6 signature sign off they need to write a single line of code.


  • John D - June 19, 2007 at 3:35 pm

  • Thanks for writing this article.

    I’ve been a big proponent of these methodologies for years. But it was hard to evangelize them without names.


  • Tiffehr - June 19, 2007 at 3:44 pm

  • I would add All-But-Vacuum Management to the list. Team members operate with no lead/managerial/exec feedback or processes—just rumor handed down— until project stagnation and butting-of-heads gives leads and execs enough one-sided whining to do something pointlessly drastic. This avoids ever having to deal with team members as humans or actually evaluate anyone’s performance, or define anybody’s role.

    While those symptoms are relatively new to my experience, I’m starting to understand that it might be the most toxic of all.


  • Steven F. Lott - June 19, 2007 at 4:17 pm

  • Next Year’s Dollars Don’t Matter (NY$DM). When following this approach, every dumb decision that creates a potential maintenance or portability nightmare is elevated to “essential” because maintenance dollars are in next year’s budget, and don’t matter for this development project.

    Indeed, the absolute worst crud can be preserved because it is an “investment”. Rewriting and replacing the crud would only spend this years dollars on an effort that wouldn’t have any tangible ROI until several years in the future. The idea that maintenance is usually forever (the service life of in-house software appears to be measured in decades) has no impact at all, since that gigantic maintenance budget is only spent one year at a time, and it’s made up of next year’s worthless dollars.


  • Terry Bleizeffer - June 19, 2007 at 4:27 pm

  • Brad – On “poorly written specs”, I spoke to a developer who would receive a huge UML diagram as their spec – converted to a 200 page Word document. The great part is that when a new requirement was added, the architects would update the UML diagram, re-gen the Word doc, and send it to the developers… who would then need to pour through the 200 pages trying to figure out what had changed! What would that be? Obfuscation-Driven Development?


  • Scott - June 19, 2007 at 4:30 pm

  • Also: I totally forgot about management anti-patterns, which will be of interest to those entertained by this thread.


  • Steve - June 19, 2007 at 6:10 pm

  • Shovel-Driven Development

    Get it out the door as quickly as possible, cut-n-paste from anything that you find that works on Google, if it works it’s ready. Closely related to “Duct-tape Driven Design”


  • Nathan - June 19, 2007 at 6:30 pm

  • BDD: Blog Driven Development

    Developers who are constantly thinking about the subject of their next blog post. Nearly every somewhat interesting line of code they write is extracted into a blog post.


  • GioSico - June 19, 2007 at 9:00 pm

  • Or how about a dev shop with all of the above? :)


  • WatchingItAll - June 19, 2007 at 9:53 pm

  • On GioSico’s post:
    I work at Hilton (rated #11 best place to work). I see this in so many groups there. Anybody else feelin’ it in the corporate world? Currently, I see all the dev types in my group. It’s unbelievable.


  • master - June 19, 2007 at 11:04 pm

  • Ass Licking Management (ALM) – This is the management which is ready to lick its employee’s ass to keep them in the company…Most of the time, these employees follow GMPM methodology by finishing the assignment with hacks.


  • Ryan Davis - June 19, 2007 at 11:36 pm

  • How could you leave out the NIH (not invented here) methodology?


  • halcyon - June 20, 2007 at 12:38 am

  • Over-engineered Ãœber-specified Development (OÃœD) where 90% of the development time is spend on over-specifying architecture, service interfaces, requirements and other things which do not get build, because the project is 3 years late and gets canceled.


  • Jellybob - June 20, 2007 at 2:01 am

  • How about Budget Driven Development (BDD)? It’s the way we seem to work here, where the time that a project will take is dictated by how much the client will pay, instead of how long it will take to develop the application, generally leading to massively over-budget projects.


  • wbucks - June 20, 2007 at 2:28 am

  • How about – Don’t Know Technology Dev (DNTD) Part of the furniture workers have this down to the tee – you claim not to know the technology just so you don’t have to be involved or bothered.


  • Arve - June 20, 2007 at 3:25 am

  • IMBADD – Idiot MBA-Driven Development. Early this century I worked for a shop doing visualization for real estate, and I had done a mock-up of a CMS that converted autocad files and other material, blending this in with typical sales material. Done by one man in just a few weeks. Getting something usable would be at the very least one and a half to two man-years. Making it sellable a bit more. My manager, an MBA, sold licenses for the dummy and gave me one month to finish it. Alone. And for a price of approximately one fifth of what it would cost us to run the system in that state. Needless to say, we closed shop shortly after.


  • hub - June 20, 2007 at 3:44 am

  • What about – Never Ending Story Development (NESD) This can happen if mangement is weak and you have strong tech personalities that keeps a project in constant state of aimless refactoring.


  • DasAlbatross - June 20, 2007 at 6:00 am

  • How about – Out of Scope Development (OSD) where every request or idea, no matter how unrelated gets approved and expedited as long as it might sell one more piece of software or make one customer happy already. This is despite the fact that any monetary gains will be offset by the rising development costs of maintaining a hodgepodge of unrelated features.


  • Achim - June 20, 2007 at 6:49 am

  • When two or more of the above are in effect the guys that really have a clue often get into
    IWIWSE mode (I Wish I Was Somewhere Else) which produces some of the most unmotivated code in existance.


  • Broccoli - June 20, 2007 at 6:51 am

  • Decapitated Chicken Process – A time honored micromanagement technique where each day managers identify a drastic emergency and require developers drop what they are doing (and whatever process they are using) and immediately attend to the latest conflagration. Since this does the double duty of creating new bugs and making other tasks fall behind, fires become easier and easier for managers to spot and then freak out about. Practically a standard in the games industry.


  • Venkat - June 20, 2007 at 7:35 am

  • Blame The People Worked and Left (BTPWAL): When you see a glitch, doesn’t matter whether your code caused it or not…through it on the people worked on this project and left the organization. I see this frequently in consulting environments.


  • Glad I'm Not Alone - June 20, 2007 at 8:31 am

  • This is a precious post. Awesome! It helps to know that I’m not alone in seeing many, if not all, of these regularly. WatchingItAll: to answer your question of “I see this in so many groups [at my company]. Anybody else feelin’ it in the corporate world?” I have worked at a two Fortune 500 companies and a Fortune 100 company. I saw these things regularly. At one company, a buddy and I would shake our heads in dismay regularly.


  • TunnelRat - June 20, 2007 at 9:37 am

  • Great post — But NADD (Not Allowed To Do Development) definitely belongs on the list. With SARBOX rules and all sorts of ‘methodologies’ touted by analysts or PMs, it’s surprising any development is actually done. The ratio of lines of code to lines of documentation is now about 1 to 1000 in most companies — which means garbage specs and even worse code that had to be cranked out quickly because most of the project schedule was spent in the “design” phase. Who hasn’t come across the clueless IT manager who asked why the coding was taking so long, considering all the time that was spent in design? Whenever you hear the terms Waterfall or SDLC, beware. Those are code for BIG DESIGN UP FRONT, which means NADD.


  • Joe - June 20, 2007 at 11:12 am

  • IWTWD (It’s What They Wanted Development) — Absolving oneself of all accountability by inventing a group of people known as “they” and blaming them for one’s own inability to design and develop a usable system.


  • Ron - June 20, 2007 at 11:56 am

  • VDD — Visibility Driven Development: We’re selling the company, so the more times the not-really-ever-going-to-be-product squeaks, whistles, spins, churns, flashes, or wobbles, the better.

    If it “just works,” it makes us look like we kept all that money we said we put into R&D.


  • Paul - June 20, 2007 at 12:58 pm

  • How about the LTDT (Leave This, Do That) development? The kind that happens when nobody actually has any master plan about things and the whole development is purely reactive? No module gets finished properly as people jump to the next bug/feature/module on an almost hourly basis. It’s a lot of fun.


  • Lisa - June 20, 2007 at 1:26 pm

  • Operation Death Star (ODS): Develop until one critical function is operational, declare the product “fully operational” and schedule a test. Watch all the important people jump ship just before the test. You’ll feel it in the force when the test blows something up.


  • Guyo - June 20, 2007 at 2:28 pm

  • ILTCASISTLCE: I’m Leaving The Company Anyway, So I’ll Structure This Like Crap Engineering.


  • Chris - June 20, 2007 at 3:37 pm

  • Closely related to All-But-Vacuum Management shown above is Mushroom Management Development (MMD) where the developers are fed lots of crap and kept mostly in the dark.


  • Lynn Cherny - June 20, 2007 at 5:12 pm

  • Argh. Yes, a great post, and an excellent comment-thread. For the Fortune 100/500 etc. people — yeah, I’ve seen it everywhere. I have a friend in the government (a former computer science PhD) who says to me regularly, “Wow, I thought your problems only happened in the government!” So why is it so bad out there? Why are so many companies that do software development so f*^&!-ed up??

    Can I add: Overtime Development (OD), and Irrelevant Development (And We Know It), for projects that serve no real need, are never tested, and may ship, but are never used? The soul-killer.


  • Chipping the web - surprise -- Chip’s Quips - June 20, 2007 at 5:59 pm

  • [...] often amazed at the longevity of code that employs these priinciples.  Couple that with Asshole Driven Development (again via Assaf), and your project will never [...]


  • Dave Joyce - June 20, 2007 at 9:09 pm

  • Having recently left a major BDD group and now acclimating myself to a full-blown ADD organization, I am confronted with a major philosophical question: why do companies hire developers with specific areas of expertise and knowledge only to muzzle them and dictate the ‘how’ of projects, instead of the ‘what’ that they should be providing?


  • srinayan - June 20, 2007 at 9:20 pm

  • nice post. This reading this is working like a reverse vent for me


  • Comanche Hill » links for 2007-06-21 - June 20, 2007 at 11:22 pm

  • [...] scottberkun.com » Blog Archive » Asshole driven development (tags: development programming methodology management software) [...]


  • Sunil Swamy - June 21, 2007 at 2:20 am

  • BQAD (Blame the QA Development) or QASD (QA s*cks Development) – An advanced CYAE. This is a kind of development where you blame on QA for everything. If your company has incomplete specs, and you are a messy coder who likes to skip reviews and not write any unit tests – then just relax and try the BAQD or QASD….
    It works for sure..


  • jkekoni - June 21, 2007 at 3:47 am

  • MSBoC Model structure by organisation chart. The software and or/database model is based on origanisation or organisations producing/using it regardless of the soundness of the design or needed duplicated data/functionality.


  • starcatcher.ca : Asshole-Driven Development - June 21, 2007 at 4:20 am

  • [...] is a blog post on the latest in the trend of programming methodologies that take a more, ahem, *realistic* view at corporate and software development culture. While I may [...]


  • sickdevloper - June 21, 2007 at 4:46 am

  • well im joining new company.. rite now passed thru two types of development processes GMPM andn ADD. This is going to b my third comp. I expect the process might be Blame The People Worked and Left (BTPWAL) because they are hiring in mass and there are only months left to release.


  • afajem - June 21, 2007 at 4:47 am

  • Faith-based Development: Based on the premise that a developer is so good (read: cocky) at what he/she does that he need not unit test or ensure that the damn thing works with other existing components but just checks in the code as-is.


  • Wolfgang - June 21, 2007 at 4:48 am

  • NDD – Nerd Driven Development. Requires every new and fancy technology to be used in the next project. Just for the sake of it, no matter whether it actually make sense.


  • Wolfgang - June 21, 2007 at 4:51 am

  • The NGL (Never goes live) approach expects the outcome of the project never to hit the market. Hence all requirements to operation, extensibility or reusability are considered no or low important


  • John - June 21, 2007 at 4:59 am

  • How about CPT (Can’t Polish a Turd) development, This is where management cannot understand the need to stop and fix/clean up/refactor or start again.

    And WSIA (We Sold It Already) development. I once went to a meeting where we were told the timescales for a project that we had not given any feedback for and told that there was four hours allocated to write the functional spec for a 2 year (our estimate) development.

    Dilbert rools:

    http://www.dilbert.com/


  • Damn, I've been found out at hagerty.net - June 21, 2007 at 5:02 am

  • [...] This guy has called me out – he’s discovered my software development management style w/o ever even working for me! [...]


  • chad baber - June 21, 2007 at 5:21 am

  • This article and subsequent replies needs to be published as a reference material for use in Computer Science and Systems Engineering classes in universities around the world. Another place crying for distribution is in our government where we manage to spend mega dollars in at least half of the above mentioned “methodologies”. BTW is this what “paradigm” means?


  • Nitin - June 21, 2007 at 5:22 am

  • Cool post… Most of the things I have encountered in day to day life over past 10 years of software development are covered.


  • gummih - June 21, 2007 at 5:28 am

  • GTMGTFM (Get The Money, Get The Fucking Money!) methodology usually makes good use of the ADD approach.


  • Minaki Serinde - June 21, 2007 at 5:47 am

  • NKWYWUYSI (Not Knowing What You Want Until You See It) Design: We get this one all the time. Management know they want something but they’re not quite sure what – so there is no design spec. What they want then gets poorly communicated down to the dev team, who then produce their version of what they think Management wants, and then the project enters the NESD (Never Ending Story Development) phase.


  • Chris - June 21, 2007 at 6:35 am

  • With all those development methods, don’t forget to use the “TBTTFNSC Framework”; the “The Boss Thinks That Framework’s Name Sounds Cool” Framework! Always a good pick to start a new project.


  • Jonathan Ghent - June 21, 2007 at 6:42 am

  • This is one of my favorite articles on software development.

    “‘People ask, doesn’t this process stifle creativity? You have to do exactly what the manual says, and you’ve got someone looking over your shoulder. The answer is, yes, the process does stifle creativity.’ And that is precisely the point.”

    If you work on a project that is important enough that lives depend on it, expect to be dictated the “how” as well as the “what”. Its part of computer science, as the article points out.


  • Caleb - June 21, 2007 at 6:51 am

  • Great post. I just recently left an ADD workplace, and it’s a breath of fresh air. It’s like I’ve won a prize.


  • John - June 21, 2007 at 7:04 am

  • Closely related to “Duct-tape Driven Design” are similar patchwork style methodologies LHFD (Low Hanging Fruit Development) and PLRA (Path of Least Resistance Architecture).


  • admiral - June 21, 2007 at 7:06 am

  • This article (with compiled-in comments) should be in Wikipedia!


  • Bill - June 21, 2007 at 7:13 am

  • My favorite is DMWD – Dead Man Walking development.

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


  • JohnnySex - June 21, 2007 at 7:18 am

  • Man you are some angry developers.


  • MAV - June 21, 2007 at 7:32 am

  • Don’t forget the 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.


  • Code Commando - June 21, 2007 at 8:01 am

  • DBC – Development By Crisis (Management By Crisis).
    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.


  • John - June 21, 2007 at 8:10 am

  • How about CCWC (Can’t change won’t change) development. 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.


  • Bruce - June 21, 2007 at 8:17 am

  • Don’t forget WHACD (Without Half A Clue Development – pronounced “whacked”) and WAMM (Whack-A-Mole Management) where management feels compelled to beat down any heads rising above the rest.


  • Jack Wilson - June 21, 2007 at 8:23 am

  • I just went through a project run by Asshole Driven Development. The Marketing Director made all the shots. In most projects where collaboration tools can be a good thing, it killed us. We used an annotation service (protonotes.com) to add notes to our prototype and the Marketing Director would go on annotation tirades in ALL CAPS shouting about how bad the design was.


  • Chase - June 21, 2007 at 8:34 am

  • TMCD – Too many chiefs, 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.

    TPD – The process development    . 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.

    ITD – It’s Tuesday development    . 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.


  • Connor Murphy - June 21, 2007 at 8:51 am

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


  • Clarence the Clown - June 21, 2007 at 9:45 am

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


  • Bill - June 21, 2007 at 9:55 am

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


  • Bill - June 21, 2007 at 9:59 am

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


  • woodstock - June 21, 2007 at 10:03 am

  • 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


  • Mr. Boddy - June 21, 2007 at 10:11 am

  • NST Development – Next Shiny Thing Development. When your development focus changes every time your boss comes back from a tech conference.


  • Bluezombie - June 21, 2007 at 10:13 am

  • Obviously Scott Berkun knows too much. Black helicopters should be dispatched to his location immediately.


  • MicroMuncher - June 21, 2007 at 10:31 am

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


  • Dan Sniderman - June 21, 2007 at 10:50 am

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


  • dave - June 21, 2007 at 10:52 am

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


  • Jeff - June 21, 2007 at 11:03 am

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


  • RW - June 21, 2007 at 11:04 am

  • 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!)


  • Loki - June 21, 2007 at 11:23 am

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


  • architect - June 21, 2007 at 11:27 am

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


  • DCAustinite - June 21, 2007 at 11:41 am

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


  • Kaizen - June 21, 2007 at 11:44 am

  • 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


  • Ian - June 21, 2007 at 12:11 pm

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


  • Trumpi - June 21, 2007 at 12:28 pm

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


  • Paul - June 21, 2007 at 12:59 pm

  • 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!”


  • A$^#*@e Driven Development : BobCrosley.Com - June 21, 2007 at 1:34 pm

  • [...] There are a lot more good methodologies there. I have some brutal personal experience with both Never Ending Story Development (NESD) and Out of Scope Development [...]


  • Joe - June 21, 2007 at 1:45 pm

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


  • Santosh - June 21, 2007 at 1:52 pm

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


  • jobrien - June 21, 2007 at 2:30 pm

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


  • Tony - June 21, 2007 at 3:19 pm

  • This is something I wish I had read before I left university


  • PJR - June 21, 2007 at 3:38 pm

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


  • Steve Cavin - June 21, 2007 at 3:50 pm

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


  • Mohamed Atef - June 21, 2007 at 4:44 pm

  • 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 :)


  • GlenF - June 21, 2007 at 4:50 pm

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


  • jeff - June 21, 2007 at 6:32 pm

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


  • Sean - June 21, 2007 at 6:35 pm

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


  • links for 2007-06-22 at The New Reader - June 21, 2007 at 7:33 pm

  • [...] scottberkun.com » Blog Archive » Asshole driven development (tags: agile dev programming management software methodology development) Published by ichen June 22nd, 2007 in General [...]


  • Johnny - June 21, 2007 at 8:25 pm

  • 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. :)


  • Ness - June 21, 2007 at 9:43 pm

  • Thanks for the post and the comments. I forwarded them to our CTO for review. We have a lot of ADDs!


  • rvdavid - June 21, 2007 at 9:55 pm

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


  • Mark Miller - June 21, 2007 at 10:04 pm

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


  • Mark Miller - June 21, 2007 at 10:18 pm

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


  • Guy - June 21, 2007 at 11:12 pm

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


  • DMG - June 22, 2007 at 1:05 am

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


  • wowbagger999 - June 22, 2007 at 1:16 am

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


  • Rich - June 22, 2007 at 1:34 am

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


  • LJ's 2 cents - June 22, 2007 at 2:10 am

  • 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


  • Joe - June 22, 2007 at 4:54 am

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


  • Adam - June 22, 2007 at 6:36 am

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


  • {codesqueeze} - June 22, 2007 at 6:57 am

  • Squeezed Links : June 2007…

    Asshole Driven Development – A hilarious and honest play on our industry acronyms by Scott Berkun.
    Classic Mistakes Updated – Steve McConnell updated his Classic Mistakes list as originally written in the timeless book Rapid Development.
    In Programmin…


  • dave - June 22, 2007 at 8:23 am

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


  • Ad - June 22, 2007 at 9:18 am

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


  • David - June 22, 2007 at 9:28 am

  • Best blog post ever.


  • Robert Oberland - June 22, 2007 at 9:53 am

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


  • John Carter - June 22, 2007 at 1:06 pm

  • Those of us in Academia can’t forget:

    TDD – Tenure Driven Development

    and

    ISIFD – “I Swear It’s Feasible Development”


  • Matt - June 22, 2007 at 1:48 pm

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


  • Roach - June 22, 2007 at 2:13 pm

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


  • Jeff - June 22, 2007 at 2:14 pm

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


  • Notes from a Tool User - June 22, 2007 at 2:20 pm

  • Carnival of Agilists for June 22/07 – In Progress…

    People Over Process In one his all too infrequent posts Pete Behrens reminds us that is all about the people and not the practices: Scrum is Team-Driven Development. Johanna Rothman reminds us the Standup is about the team and not…


  • Big Dave - June 22, 2007 at 2:25 pm

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


  • Sandesh - June 22, 2007 at 2:36 pm

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


  • Evac156 - June 22, 2007 at 2:41 pm

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


  • MJPS - June 22, 2007 at 2:45 pm

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


  • john - June 22, 2007 at 3:47 pm

  • You forgot about PMW: Project Management Warlordism where project managers act like turf-centric warlords …


  • Brian - June 22, 2007 at 5:57 pm

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


  • jc - June 22, 2007 at 7:50 pm

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


  • Vitorio - June 22, 2007 at 8:19 pm

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


  • links for 2007-06-23 - June 22, 2007 at 9:20 pm

  • [...] scottberkun.com » Blog Archive » Asshole driven development 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? (tags: agile development software methodology programming funny antipatterns) Tags: [...]


  • NiKo - June 22, 2007 at 11:15 pm

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


  • Chadwick - June 22, 2007 at 11:48 pm

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


  • links for 2007-06-23 « Joost’s weblog - June 23, 2007 at 1:24 am

  • [...] Asshole driven development (scottberkun.com) Great acronyms to specify what kind of development is taking place in the software team. I like the DBD approach (tags: development management software architecture method) [...]


  • Thomas - June 23, 2007 at 9:07 am

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


  • Jim Holmes - June 23, 2007 at 11:26 am

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


  • zaki - June 23, 2007 at 12:13 pm

  • I cant help but keep laughing. When i think i want to add something, its already there said by someeone. Great Post!


  • WithoutNoise - June 24, 2007 at 2:14 pm

  • [...] Berkun has a great article over at his blog about *sshole Driven Development, or “ADD.” “Any team where the biggest jerk makes all the big decisions is *sshole driven development. [...]


  • Simon - June 25, 2007 at 4:37 am

  • Gartner Driven Development (GDD) – Any project where the technologies are chosen based on what is in the ‘Magic Quadrant’ on the day. Long projects and projects where there is a Gartner conference in the middle are particularly susceptible


  • Stabby - June 25, 2007 at 7:32 am

  • Related yet relevant development angst: http://www.waterfall2006.com/

    I particularly recommend the links on “refuctoring” and “The Joy of Silence: Cube Farm Designs That Cut Out Conversation”


  • Eric - June 25, 2007 at 1:41 pm

  • Schedule Chicken Development - Continuing with your rosy status emails about how everything is on track while hoping that somebody else is more messed up than you are, and will be foreced to announce a slip


  • Engin - June 25, 2007 at 2:26 pm

  • What The F.CK IS GOING ON DEVELOPMENT (WTFIGOD): As the name applies, nobody knows what is going on, but still keeps working on their assigned tasks. That kind of development process usually ends up in misery for both the company and its customers…


  • Fred - June 25, 2007 at 4:06 pm

  • Anything But Microsoft (ABM). They seem to go out of their way to not use .NET or other Microsoft frameworks and languages. Java, PHP…even Rails, just anything but Microsoft. Bugs the heck out me.


  • Armen - June 26, 2007 at 1:45 am

  • Excellent blog. Awesome. It is so nice to find out that you are not alone. I am suggesting to summarize and filter all added methodologies and write an article about it. Like Martin Fowler has “Bad Smells” in refactoring we could have something like “Bad Methodologies” in development. By my opinion the next and important step should be to bring the solution to each “methodology”: how to solve, how to avoid etc. Again really good blog and comments.


  • woodstock - June 26, 2007 at 6:24 am

  • SWAPIT: Usually applied in outsourceing. Several people in the client company are not really happy in their positions so management swaps the functions in the IT department every now and then. CM becomes spec lead, tech lead becomes spec lead etc. This results in changes in the CM process, Features and technologies used. Project gets over budget and features are dropped.
    DUH!D: Used in TPDD (Teachers Pet) but in this case the pet (tech lead) has a complete and utter lack op knowledge regarding the project, project scope and the technologies used. Sentences in DUH!D will usually start with or contain words like “ehhr”, “ehhmmm”, “maybe”, “let me see”, “what if” or “I don´t know”.
    BLD: Blurring Layer Developement. Usually used in DUH! and SWAPIT. Developers are not allowed to directly contact the persons responsable everyone is only allowed to contact the next link in the chain, who thinks he´s important enough not to change the wording in the question and adding his own doubts to the question instead of just forwarding the question. This results in a completely different question answered correctly but the answer gets blurred also resulting in the developer waiting five days to obtain the wrong answer to a quastion he has never asked.


  • woodstock - June 26, 2007 at 7:58 am

  • CDD: Certification Driven Development. Generally used in MUSTP projects. You create a group of developers with lots of certifications and zero experience and consider the project must be successful since everyone is dully certified on the used technologies. CDD is oftern a client requirement.


  • woodstock - June 26, 2007 at 8:41 am

  • FSD or IDIMWD: Frank Sinatra Development. This method is based on the famous Frank Sinatra song “I Did It My Way”. Each developer in the project is passed tasks at random without any coherence to subsystems or developer knowledge. Non of the developers actually knows what the other is doing and there is no coding standard. Each task is implemented as the developer sees fit which results in replicated funcionality throughout the system.


  • Theresa - June 26, 2007 at 10:30 am

  • I especially like a combination approach: asshole + chicken with their heads chopped off + i’m leaving anyway + obfuscated + not allowed to develop/not allowed to make a decision.

    And to think, as a consultant, you have to know all these approaches. People say “do you know Agile?” as if it matters… Managers are hallucinating if they think they’re following any “real” process.


  • Simon Wardley - June 26, 2007 at 10:46 am

  • BORED : Blindingly obvious regurgitated “enterprise” development.

    Discovering that whatever you built with the BAUD method (see previous comment) can be repackaged and sold on in small $20K bundles to lots of other companies as providing “strategic value” in an “enterprise” environment. This can safely be achieved as most businesses have little way of ever identifying or measuring value of IT and if you are asked just tell them their competitors are evaluating it and mention the words “Competitive Advantage”. Well no-one wants to get left behind.

    This is also known as Keeping Up with the Jones’ (KUJ development) and other such terms and is in widespread use.


  • Simon Wardley - June 26, 2007 at 11:33 am

  • WMD : Wrong Methodology Development.

    This is the approach of using static like processes of project management to solve dynamic classes of problems and vice versa. Generally leads to corporate carnage through massive cost over-runs and cancellations. Unlike the other form of WMD, it does not lead to MAD (mutually assured destruction) hence preventing its use. Instead it is commonplace and used frequently within corporate boundaries, leading to a situation that MADness is the common state of affairs and WMD is applied liberaly.


  • Caleb Jenkins - June 26, 2007 at 11:42 am

  • I think that we left off the MPP – Marco Polo Process. That where the customer stands in one spot and says “Marco”, and so the developers start blindly coding in that direction, only to get there and find that the customer has moved yet again, “Marco!”, so we start blindly coding again in another direction. Process continues until everyone gets tired and decides to finally get out of the pool.

    “Polo!”


  • Scott - June 26, 2007 at 7:07 pm

  • If this wasn’t enough for you, and you want more commentary and painfully funny methodologies there are additional comment threads on the three major drivers of traffic: Digg, O’Reilly Radar, And Reddit.


  • Mark Serlin - June 27, 2007 at 1:47 am

  • I’d think all this was very funny if I weren’t crying into my capuccino right now, having recognised ADD, CDD, LHD, CPM, IMBADD to name but a few.


  • alexdp - June 27, 2007 at 8:43 am

  • CNP – Chuck Norris Process : a developper works on a project. Then another takes it in charge. Glups! he realises that his colleague worked applying the NoDDD – No Design Driven Development. Wooo, there’s only one solution : do what Chuck Norris would do. So, he has to take the code, kick it, send it into orbit, and re-develop all the project again. Thanks Chuck. You’re welcome!


  • One Measly Dollar » Blog Archive » links for 2007-06-25 - June 27, 2007 at 12:13 pm

  • [...] scottberkun.com » Blog Archive » Asshole driven development Essential reading for all managers, directors, project managers, owners, bosses, senior-vice presidents, presidents, senior directors…of course the people that need to read stuff like this never realize that THEY are guilty of these things, so what’s th (tags: development methodology management work humor programming) Posted in Daily Links by phil.leitch RSS 2.0 [...]


  • woodstock - June 28, 2007 at 5:35 am

  • BFSDD: Big Fucking Snowball Driven Development.

    Early in the design process, Management is warned about possible flaws in the design, but decides to ignore them completely. During early development, it becomes clear to all developers that there actually is a problem and a meeting with management is held. During this meeting it is decided that, since we´re already some weeks into development we should continue with what we have and try to work around the problem. This is where the snowball is created. After the meeting developers start to complain more and more and many CMA emails are sent but management keeps pushing the snowball around. The snowball gets bigger and bigger and new management functions are created with names like Tech Coordinator or Tech Advisor who when the get into the job hold meetings to discuss the problem. When he poses the problem gets whacked down to earth by management and is told to just help and push the snowball. About three quarters into development the snowball has become so fucking big that the management team, which is now bigger than the development team, is no longer able to push the snowball around and the development team is told to “solve the fucking problem”. What could probably have been fixed in one or two weeks when the snowball was created will now result in huge cost overruns.


  • woodstock - June 28, 2007 at 5:47 am

  • BBFBFLDD: Build Building First, Build Foundation Later Driven Development.

    According to management, they need to show results to the client. Result is considered as something the client can actually see. Considering this huge amounts of time and effort are put into creating this awesome GUI that is held together by stubs so “functionality” can be “demonstrated” to the client. Only late in the development cycle management remembers that the application should actually work with real world data and not stubs and some gurus will be put to work on the backend. However many of the cool features as shown using stubs are really difficult to get really working. Some peaces of the GUI have to be changed and the beautifully designed building (Tower of Pisa) becomes crooked and may even fall down. BBFBFLDD usually leads to huge budget overruns and an unsatisfied client.


  • woodstock - June 28, 2007 at 7:00 am

  • I have two questions. The first to Scott:

    - Can we look foreward to a book about some of these development methodologies, maybe including some “success stories”?

    To all:
    - Is there anyone that has ever been involved in a project where not one of the above mentioned development and management strategies has been used?


  • Sam Bendayan - June 28, 2007 at 9:51 am

  • I’ve seen the FINAO methodology (Failure Is Not An Option). This is the belief that if management pushes the developers hard enough then ANYTHING is possible. May also be known as SDD (Slave-Driven Development), DMD (Death-March Development), or KDD (Kamikaze-Driven Development). Outsourcing is a variant of this, where you can get Third World managers (who have much more experience in SDD) to handle the distasteful ‘Slavery Management’ aspects of the project for you. That way you can sit back in the corner office of your crumbling software company and admire yourself.


  • onemorecoder - June 28, 2007 at 10:05 am

  • Management By Panic (MP) methodology. Every management action is predicated by an “emergency” change. Usually executed in the absence of planning.


  • onemorecoder - June 28, 2007 at 10:11 am

  • Time Dialation Driven Design (TDDD). This methodology is characterized by a composition of excessive featuritis preceded by excessively short release timelines. It is usually practiced by managers and team leaders who exhibit a fascination with science fiction and quantum theory.


  • Glad I'm gone - June 29, 2007 at 6:03 am

  • You’ve heard about the proverb, “Give credit where credit is due.” Well, the management at one company I worked for worked on a “Take Credit Wherever It Remains Unclaimed”.


  • Sorcerdon - June 29, 2007 at 8:30 am

  • I know how it feels when you do everything in your power to keep things running, even reviving the company, and then you get shot in the leg for doing it.
    When you tell your “manager” (who is the CTO) that X and Y are REQUIRED and in return all you get is a letter saying “keep this confidential…” or “we don’t want word getting out that…”

    When the wrong person is in charge, the wrong people get fired. Ignoring past relationships, ignoring all you’ve ever done, ignoring everything you contributed, you get nailed by that ignorant fool.

    This is what I call DWITSPD (Dude, Where Is The Software Professional? Development)
    Another name is DTAD (Don’t Touch Anything Development) or DCAD (Don’t change anything development). Did I forget to mention the “Or ELSE you get fired” quote after that?

    When everything is NOT working, and the RIGHT people ignore it by firing the people that realize it, THAT is when you know you’re in the wrong company…

    And that’s all I have to say about that.


  • Dasmotiu Zodalif - June 29, 2007 at 1:57 pm

  • IFMIMBG (It’s From Microsoft, It Must Be Good) The opposite of ABM, probably occurs way more often than ABM too.


  • Chui's counterpoint - June 29, 2007 at 8:25 pm

  • Fantasy Development Methodology…

    Scott Berkun’s talks about dysfunctional development methodologies.
    He has left out Fantasy Development Methodology.
    Here are the basic steps:

    Sales promises delivery of fantasy product on a fixed cost fixed time basis
    Business analyst specs up …


  • Elegant Code » *DA : Buzzword Driven and Oriented Architecture, Design, and Development - July 1, 2007 at 9:06 pm

  • [...] (SOA) Service Oriented Architecture, (MDA) Model Driven Architecture, (MDE) Model Driven Engineering, (MDD) Model Driven Development, (DDD) Domain Driven Design, (EDA) Event Driven Architecture. (TDD) Test Driven Development. (FDD) Feature Driven Development, (EDP) Event Driven Programming, (BDD) Behavior Driven Development, (AOP) Aspect Oriented Programming, (COP) Concept-oriented programming, (AOP) Attribute Oriented Programming, (OOP) Object Oriented Programming, (COP) Component Oriented Programming, (SOP) Subject Oriented Programming, (POP) Process Oriented Programming, (FDP) Flow Driven Programming, (CDD) Contract Driven Development, (RDD) Resume Driven Development, and Asshole Driven Development. [...]


  • Infovore » links for 2007-07-01 - July 2, 2007 at 12:53 am

  • [...] scottberkun.com » Blog Archive » Asshole driven development “Any team where the biggest jerk makes all the big decisions is asshole driven development.” This, and many more gems, can be found in this Scott Berkun blogpost. (tags: development practice methodology management software programming humour) [...]


  • Tina - July 2, 2007 at 8:25 am

  • Who the f*k thought of this?!? (WTFTOT) – When individuals so far above the developers pay grade have a stupid idea and never thought of passing it by anyone who actually had a clue. These are the best applications because they end out making no sense


  • Sam Bendayan - July 2, 2007 at 9:31 am

  • I read the Time Dialation Driven Design (TDDD) post and it gave me an epiphany. Maybe these managers truly are smarter than we think and all they’re trying to do is apply Einstein’s Theory of Relativity. You see, if they crack the whip hard enough and speed up their development team, they are hoping that time will actually slow down and allow them to finish an otherwise impossible project on time.

    The problem is that we won’t work hard enough….we have to work at near the speed of light for the theory to kick in, so they need to push us…..HARD. THAT’s the answer…


  • blogBit » Asshole driven development - July 2, 2007 at 11:12 pm

  • [...] rarely talk about my job, but I’m a software engineer. And one of my collegues sent this to me and made me laugh harder than I have in weeks. [...]


  • Danilo Gurovich - July 3, 2007 at 9:23 am

  • Loved your ADD essay, I also loved your link about the anti-patterns that have become prevalent. I just wrote an article concerning “Involuntary Prototyping” where Product/Dev get involved in horrible QE cycles due to incomplete development and unrealistic dates. It plays into a great deal of your humorous points, although the tone is more serious.

    http://danilogurovich.wordpress.com

    I will link your blog. Nice stuff.


  • ciphersimian - July 3, 2007 at 11:27 am

  • DNBM: Design None, Build Many: Characterized by simultaneous development of new features for multiple new products on multiple new hardware platforms before determining the ‘design’ of any of the features is sound on a single product/platform.


  • Mario - July 3, 2007 at 3:48 pm

  • I’ve frequently seen something like NST (New Shiny Thing) Development, called MDD or FDD — Magazine Driven Development or Fad Driven Development. The technology to use is determined by the latest magazine the AIC (Asshole In Charge) has read. See also RDA: Restaurant-Driven Architecture. The choice of technology is driven by which vendor takes the AIC to the nicest restaurant.


  • The Geek Inside » Asshole Driven Development - July 4, 2007 at 4:56 pm

  • [...] el buen Norbert me pasó la liga a un artículo muy bueno acerca de metodologías alternativas para el desarrollo de software (je je je [...]


  • Shari - July 9, 2007 at 4:57 am

  • This is hilarious! Thank you all for putting into words what has caused me endless nights of unrest! ADD hahahaha….


  • Fun with Development Methodologies « SW Engineering Blog - July 11, 2007 at 5:15 am

  • [...] 11 Jul 2007 Fun with Development Methodologies Posted by brianeno under Fun  This hilarious look at acronyms for development methodologies has been mentioned a few times in the blogosphere but if you haven’t read it yet, do!   [...]


  • Marcelo Daibert - July 11, 2007 at 5:05 pm

  • Hello,

    And where about the L24-DD: Learning in 24 Hours Driven Development.

    Teach you self books users.. =)


  • Jay - July 12, 2007 at 5:06 am

  • RTBADNM

    READING THE BLOG AND DOING NOTHING METHODOLOGY

    this is what all of us are doing here


  • Andrew - July 13, 2007 at 2:44 pm

  • Oops. I meant to say:

    A SCREW’EM Development Philosiphy:

    Software Created Rapidly Expecting Widespread Error Maintenance

    And… if you intend to do a really poor job, then you use this philosophy:

    SCREW’EMALL
    Software Created Rapidly Expecting Widespread Error Maintenance on All Logistical Levels!


  • BoomJubby - July 15, 2007 at 5:10 am

  • There’s always Byte-Management Dictation which is an extended form of micro-managing. You’re fidgety, incontinent project manager ,who smells like ass, drools over your shoulder and dictate lines of code that you already know how to write.


  • Will - July 18, 2007 at 8:45 am

  • Deadbeat Baseball Coach Development

    Shows up in the bottom of the 9th for the first time and if things are satisfactory he’s your best friend, if not, you’re a worthless programmer who develops applications that serve no purpose to humanity.


  • Ricky - July 18, 2007 at 10:28 am

  • Damn the Man Development (DTMD): Coding done to bypass the established constraints and policies over what it would take to comply.


  • eric miller - July 20, 2007 at 1:24 pm

  • WHISKEY methodology: Why the Hell Isn’t Someone Koding Everything Yet?

    Great list…


  • Because Java Programmers can Suck, too « Learning Lisp - July 24, 2007 at 7:05 am

  • [...] wasn’t all that fulfilling. I moved on to other things and tried to avoid such pedantic NDD (Nerd-driven development) in live systems where other people would surely come after me and hate my guts for such pointless [...]


  • Ooze - August 2, 2007 at 1:35 am

  • YOOOOOOOW…..

    WOW…
    Asshole Driven development (ADD) is exactly what I am doin rite now… (>_


  • Улыбнёмся | kraynov.com - August 5, 2007 at 1:19 am

  • [...] и для знатоков английского (спасибо тому же Алексею) – Asshole Driven Development. Читать всем IT-шникам обязательно! У меня в офисе все [...]


  • Tim - August 5, 2007 at 12:07 pm

  • NDD – Nobody Driven Development. A bit chaotic one.
    NOD – Never Optimize Development ( .Net & Java development paradigm? ;) )

    Tim
    http://gtd-tools.com


  • SeeMySites Blog » Satire at it’s best - August 15, 2007 at 10:08 am

  • [...] Wow, two in one day. There’s also the ADD list for the programmers. My personal favorite is in the comments: The decapitated chicken [...]


  • House_of_Dexter - August 16, 2007 at 3:12 pm

  • Firefighter Development…As all your development time is spent putting out fires created by the previous development team who created the project using the SCREW’EM Development.


  • Nasr Mian - August 19, 2007 at 10:34 pm

  • some of the most creative and imaginative minds are on this page, I have enjoyed most parts of it


  • Matt - August 27, 2007 at 5:47 pm

  • Just one more method Crash Driven Development CDD or Iterative Crash Driven Development ICDD where you work endlessly fixing software development with zero specs and daily manager intervention.


  • newstube.de - August 30, 2007 at 8:06 am

  • scottberkun.com » Asshole driven development…

    In der Welt der Computer gibt es viele Akronyme. Warum also nicht noch ein paar sinvolle hinzufügen. Scott Berkun macht sich in seinem (englischsprachigen) Blog unter anderem Gedanken über Projekt-Management und Software-Entwicklung. Dabei entdeckte …


  • Creepy reality, funny acronyms « Gustavo Carreno - September 25, 2007 at 7:10 pm

  • [...] someone has really put the finger on it: Asshole driven development and other true methodologies living in reality. Also have a read on the comments. There’s [...]


  • Prof_Bab - September 29, 2007 at 3:42 am

  • Damn…
    I’ve seen more Shovel-Driven Developers than lines of code. I wonder if they will EVER disappear. Also, you cannot forget:

    Don’t-Know-Shit-About-Project-Management (DKSAPM).

    Using this method you just stay all day and don’t do anything, and you let the various vertebrates under your command to write the code and to figure out what is the next step. During this time you just point out idiotic / too obvoius aspects and then brag about them to your boss. Life’s great. God help us :)


  • Lars Fosdal - November 10, 2007 at 5:14 am

  • Just One More Feature Outside Schedule (JOMFOS) – Regardless how high the pressure, how tight the schedule, or how late the project – JOMFOS product managers can always find something strategic (read: we have to land this contract) and groundbreaking (read: this one customer think it is clever) that not only breaks the current design, but also has to be squeezed in before the unmoving (yeah, right) release date.


  • Constantine Yannakopoulos - November 11, 2007 at 3:03 pm

  • Management by Guilt (MbG)

    The project is always behind schedule, the customers are never satisfied with the product, the product doesn’t sell as much as it was expected, the competition is always better/sells more/has more features/is more high-tech, other teams in the company are doing better, the team has too many members and costs way too much to the company and your salary is too high for the work you are doing.

    As a result you work 14 hours a day and weekends without specifically having been told to, you end up dreaming about your work when you sleep and eventually get an ulcer as a result of coffee abuse to stay awake and probably a ruined personal life. But no raise.


  • Einherier - December 7, 2007 at 10:09 am

  • Muahahaha,

    thanks for that. I really enjoyed reading this.

    In my carrer I mostly see the “Asshole Driven Development” and the “Cover Your Ass Engineering” aproge.

    But good luck, I also see project where everything is fine.

    Greetz

    einherier


  • Mike - December 10, 2007 at 5:01 pm

  • OMG – I couldn’t get through the first 5 comments in this thread without the proverbial milk flying out my nose! It’s all here. Every ounce of b*llsh*t we, as engineers (and dare I say, architects, because that’s where I am now and the sh*t still smells just as bad) have to deal with every day.

    This entire thread should be canonized.


  • Albert | UrbanMonk.Net - December 12, 2007 at 9:23 am

  • Agreed with Mike above, this is hilarious! No wonder you put it in the best of section!

    Cheers,
    Albert | UrbanMonk.Net
    Modern personal development, entwined with ancient spirituality.


  • Warren - January 2, 2008 at 2:46 pm

  • My cynical development methodology is called (BDD) Breakpoint Driven Development. I could tell you more about it but then I’d have to kill you, or sign you up as a consulting client. I recommend the killing, it’s less painful.

    Warren


  • RobV - January 3, 2008 at 8:45 am

  • All too much I’m confronted with the SIBBILI-effect within the ADD, meaning Seeing-Is-Believing-Because-I-Lack-Imagination.

    This professional “reason” is THE perfect excuse for doing nothing. Works every time, guaranteed!

    Saves you tons of money (and your face) too. It’s great!


  • Jimmy - January 5, 2008 at 7:46 pm

  • The list also needs to be expanded with DIAMLCDWTE development approach (Did it at my last company, didn’t work there either). This is when a new developer introduces designs and code used at his last job, which he had to leave, because the company went bust because of exactly that design and code.


  • _ Driven Development « eight to late - January 15, 2008 at 10:07 pm

  • [...] Driven Development: See this post on Scott Berkun’s blog for more. Note that he uses a stronger, perhaps more appropriate word [...]


  • Christian Aa - January 17, 2008 at 7:06 am

  • I have seen Methodology To Avoid Development (MTAD) being used quite often. You can recognize it by the waythe people in the project are way more focused on methodology than what their goals are, probably partially because they have no idea how they could do the technical part :-)


  • Stefan de Bruijn - January 24, 2008 at 12:05 pm

  • Three more:

    1. Let the Best Developers Handle The Management. Most organizations are organized in such a way the management gets paid more than development, and that management is considered superior to software development. The result is that good developers that create code 10 times faster than average developers with 100 times as little bugs tend to walk the ladder called ‘career’ and end up being worthless managers.

    2. Don’t Think, Use The Debugger. Worthless code is always going to be worthless; debugging code just results in just as crappy code with some patches to make the crap more complex.

    3. Forget to Throw Away Crap. If you’re in a project creating software you end up creating patches to the requirement specification and with that patches to the software. The result is a software package with a design that’s not fit for the requirements. Instead of throwing all this crap away and starting over , the management usually doesn’t see this as an option and refrains to maintaining the “product” (which is more expensive in the long run).


  • Ernesto - February 7, 2008 at 4:35 am

  • Cannot think of my own if no requirement exists (CToMEOw/oRQ) development – Consider the following scenario: It so obvious that the concept is not working and will lead to instability. However, that’s work to write stable re-usable code and I am lucky, cuz no requirement exist which explicitly demands stability or re-use of my code. Cool, I can get away with my spaghetti code and if the shit hits the fan, I can always blame the product manager of not having required that.


  • Blogus Maximus - February 22, 2008 at 10:30 pm

  • You forgot PAoooA

    Pulling Agile out of our Asses

    This is where the manager/vp/tech lead/half brother of the CTO read an article on Agile but didnt get to finish it before his flight ended, so he’s just making it up as he goes along.


  • Tech Life of Recht » Blog Archive » X Driven Development - February 27, 2008 at 4:42 pm

  • [...] Annoyance Driven Development – let your annoyances guide you. Probably best on one-man projects. Asshole Driven Development – Let the biggest asshole make all the decisions. Also known as Jerk Driven Development. Behavior [...]


  • NO OPeration: Complexity of Software Projects - March 2, 2008 at 2:44 pm

  • Acronym Driven Development (ADD)…

    Have you had enough of all the xDD acronyms that have emerged over the last couple of years? Do you already know all about Responsibility-Driven Development, Test-Driven Development, Behavior-Driven Development, Domain-Driven Development and Model-Driv…


  • L505 - March 9, 2008 at 11:56 pm

  • NADA – No Asshole Developers Allowed.

    This is the worst because then we can’t join.


  • M - March 17, 2008 at 6:58 am

  • Use-Case Driven Development, (UCDD). May sound good initially until you realise that **everything** has to be included in a use case. Not to mention the fact that the spec of whatever you may try to develop, might be defined in practically any of the hundreds of use cases.

    As the use-cases are supposed to describe a working system, they are usually far to important to allow mere developers write and maintain them. Instead a hoard of clueless “reviewers” decide what is possible and should be implemented.

    When everything crumbles the bosses feel that the project needs their expertise, and we get Management Driven Development, (MDD).


  • M - March 17, 2008 at 9:37 am

  • Resume Driven Development, (RDD), is a very good bottom-up methodology, where the goal is to make your resumeand hence your salary look good. It usually takes only a few developers to convince a clueless manager to bypass the conservative architect. For what we all know the architect by definition lags behind technically, especially the acronyms necessary for you to land the next well payed contract.


  • Makollig - March 18, 2008 at 8:33 am

  • How Hard Can It Be Planning (HHCIBP). Overly optimistic time plans laid by trigger-happy sales departments to meet the need of every conceivable customer.

    Usually followed by:

    How Hard Can It Get Development (HHCIGD). The desperate and futile attempts by a development department to follow such plans.


  • testuser - April 4, 2008 at 1:39 am

  • Enjoyed this one. Have personally seen ADD and GMPM in action. Had a different name for the guy best skilled at ADD, was takloo (baldy) , while GMPM was called chotu ( takloo’s butt leach ). I have been known to at times taken the CYAE approach. Finally out of the whole mess…


  • KML - April 10, 2008 at 10:27 pm

  • Coral Reef Software Development Model – codebase grows like a coral reef – a large unstructured mass that grows randomly over long periods of time by a process of accretion.


  • max - May 1, 2008 at 4:39 pm

  • IID – Isolated Island Development also called DCD Dark Cavern Development – basically, you have a single person or team of developpers, left to themselves, completely alone and/or in the dark. Then after 2 months, management comes it and ask… “so is it done?” then everyone looks at each other, and the underlying question is.. “done what?”

    IKBDUD I Know But Don’t Understand Development – Your immediate boss, or team lead knows about everything, really, having gone to university and all… but when it gets to coding shit, you realise he doesn’t understant any of it… so you end up arguing about the most basic concepts, are always right and corner him to it. But end up loosing every fight, but you lack the proper buzz word to slide in and look bright in meetings. (that’s when you say to yourself… “Yeah, should have taken that psychology class, instead of assembly” ;-)


  • Kenneth Carlo Santos - May 1, 2008 at 11:54 pm

  • Anyone Manages Planning Framework (AMPF) - A planning framework where everybody is the leader including the client that causes total mega functionality of the program or what we usually term as the “PERFECT PROGRAM”.


  • dirq - May 22, 2008 at 1:23 pm

  • How about That’s the Way It’s Always Been Done Development (TWIABDD). If I had a nickel for everytime I’ve heard that I’d have at least enough to get a lollipop.


  • F-Off Intel « Fluent Simplicity - May 24, 2008 at 6:22 pm

  • [...] Berkun: Asshole Driven Development Flaws in management, originally developed for coders but universally [...]


  • Rakesh Pai - May 27, 2008 at 5:33 am

  • You just made my day. Great list.


  • scottberkun.com » Asshole driven development: revisited - June 2, 2008 at 6:35 pm

  • [...] With the recent post on the problem with consultants, I wanted to point out the impressive inventory of failed management methods that have grown in the comments section for last year’s post on asshole driven development. [...]


  • Peter C - June 3, 2008 at 3:44 am

  • When my role in a large electronics firm was made redundant after 11 months they told me they wanted to slot me into a completely different role that they believed I was suitable for – We Can Fit You Into Any Slot We See Fit Regardless of What You Think – model of management. This arouse out of their Nimble And Flexible Firm (NAFF) model of reorganisation.


  • Jack S - June 5, 2008 at 2:37 pm

  • Almost universal method: WDNNSM, short for Methods, we don’t need no methods, we don’t need not stinking methods! Don’t give me your ‘methods’ gas. We say, ‘It compiles. So ship it!’ — I’ve lead these teams.


  • Signs of a death march software project « Small Business+Phoenix+Software - June 5, 2008 at 7:41 pm

  • [...] A great programmer (and friend) I know recently shared an absolutely wonderful blog post on new systems of software development that got me thinking.  Is there a list out there that contains all of the signs of a death march [...]


  • Declan H - June 8, 2008 at 2:37 pm

  • TLEO Methodology – Take Least Effort Option Methodology
    When ambiguities or misunderstanding exist in design or requirements never seek clarification from source – instead implement the ‘least effort’ interpretation no matter how stupid or bizarre that interpretation seems. Taking this approach allows third party developers to buy time and more cash by playing the “we implemented the specification” card and demand more money for changing the spec/design.


  • Mike - June 13, 2008 at 6:49 am

  • CRASS Methodology – Can’t Read A Software Specification

    This method of development is performed by teams of engineers who find the task of reading a specification too difficult. In some cases they may be afflicted by a condition whereby the ability to read is lost on being presented with a specification. Their only consolation in coping with this condition is that the disease rapidly proceeds to a contagious form of amnesia whereby the developers one-by-one forget that there ever was a specification in the first place.

    In many cases CRASS Development progresses into a form of:

    MOBY Methodology – My Opinion Beats Yours

    Such developments enter a terminal phase when

    WHATTA Methodology – We Haven’t Any Time To Argue

    is adopted whereby developers retreat into a virtual mental environment whereby they are capable of physically coding their own opinions. This condition is fostered by overly confident or opinionated people, since discussing implementations with fellow developers takes too much time and there just ain’t enough time left!


  • Mike - June 14, 2008 at 2:25 pm

  • NO Methodology – No Opinion Methodology

    This methodology is form of inverted MOBY (My Opinion Beats Yours) Methodology.

    Experienced engineers starting their next project when their previous project was performed using MOBY, may sometimes decide that from the outset they have no opinions whatever on either the specification, designs or implementations of fellow engineers and that everyone should be given time to work things through.

    Using NO methodology greatly increases team spirit since the only adversary the engineers have is the damn over-opinionated project manager.


  • Daud Sharif - June 23, 2008 at 2:29 pm

  • All branches of engineering are firmly anchored in natural laws.

    The exception is software engineering. It is based on laws of logic and, I submit, that mortal men are very poor at logic. Hence, our software builds sand castles in the air, when one brick is removed the whole wall disappears, and one encounters a fatal exception.

    Of course, software engineering’s immaturity of age and come one come all approach are also the problem. In the early part of 20th century one saw similar wild ideas and creations that were meant to be aeroplanes.

    I think the answer lies in using an engineering approach to software: Design-Build-Test-Fix-Re-Test.

    A word about Agile: Much I hear from the fanatics seem like short-cuts and quick-fixes for the silly customer who doesn’t know what he wants.

    Perhaps, one’s responsibility should be to provide a responsible design and a very responsible education for the customer discussing pros and cons towards a good medium and long term solution, instead of wasting time on irresponsible monthly redesigns.


  • Lee Brandt - June 26, 2008 at 11:46 am

  • Did someone mention Deadline-Driven Programming (DDP). Management and/or the client decides when they want the product delivered and the development team works like mad to try and meet that dealine. Closely related to Name that Tune Development (NTTD) where you have no requirements at all and you just keep representing the same iteration until the client is happy with it.

    Lee


  • CRM - July 21, 2008 at 4:29 am

  • I loved the CPT development above. Please tell me who posted it so I can attribute them on my site!


  • Aspguy - September 28, 2008 at 3:41 am

  • FMBFuck My Boss, is a methodology which is widely used in our company. Anytime developers stuck in a problem , they say FMB and write the easiest code just to finish the work and go home!


  • David - December 5, 2008 at 9:22 am

  • Css Cascading Style Sheets Two types of style sheets: Internal and Outer Internal – You involve your style enactment equitable into your html code. These stylesheets should one be used provided you are intending to create a particular folio with a specific style.


  • jordy - December 15, 2008 at 7:47 am

  • lol.. fun article :-)
    jordy, programmer of love calculator


  • Milan - March 20, 2009 at 3:46 am

  • Superadvanced Asshole Driven Development (SAD) alias Egomaniac Driven Development (EGO-doubleD):

    This methodology introduces manager who always more than willing to organize a meeting for every single (even smallest) decision that is needed. Then, number of different solutions and opinions is presented (including all employees) and manager is basing his decision on following complex formula: MyOpinion = NOT (Opinion1 OR Opinion2 .. OR OpinionN).

    This both proves as good standing point for ADD and as good way to tell your employees that they are completely and utterly useless. The higher the number N, the bigger the ego of good EGO-doubleD manager. The only flaw of this methodology is when employees figure out that they actually should suggest virtually all existing options. This will put good managers to test, to find an unthinkable solution which will both drive people crazy and lead project into the gutter.


  • spufidoo - April 9, 2009 at 6:26 am

  • Many of our developers suffer from AHDD – Anus/Humerus Differentiation Disorder – they can’t tell their arse from their elbow.


  • Arch - July 15, 2009 at 3:06 pm

  • The WOW symptome:

    When all the meetings and conversations regardless of the original goal quickly evolve into a heated discussion whether warlocks are overpowered or not.


  • Balazs - July 21, 2009 at 11:54 pm

  • Actually for me this highly resembles to Hungarian politics – the home country of the Neumann processor’s inventor…


  • Master of Master - July 26, 2009 at 9:36 pm

  • The Judge Is Me Development (TJIMD)- Sometimes, I as a developer have this problem to decide what should be done for the task since the task is not provided with enough information. Even has the functional specification, but it is more to the comprehensive of client level than a developer. In the aftermath, the bugs will emerge from the task and the BD(Blame it on the Developer) comes true


  • SeekingLemonade - August 18, 2009 at 3:01 pm

  • Another one…

    ATFAB = Anything For A Buck.

    When a salesman brings in a prospect, a demo app to demo is written to get a sale. Then this demo app is expected to work in all cases and configurations, where is was only designed for a quick-and-dirty. Of course by then, the developer is “too busy” to make is a real supportable product.


  • QA vs. QC - September 21, 2009 at 7:58 pm

  • [...] — unit tests, code reviews, scrum sprints, pair programming, agile requirements, TDD, BDD, ADD — but which of these would have the most impact for you specifically? Your programmers, your [...]


  • nabejero - September 25, 2009 at 6:32 am

  • [...] Source: Asshole-driven development [...]


  • QA vs. QC - September 25, 2009 at 9:43 pm

  • [...] — unit tests, code reviews, scrum sprints, pair programming, agile requirements, TDD, BDD, ADD — but which of these would have the most impact for you specifically? Your programmers, your [...]


  • SEO Manchester - September 29, 2009 at 8:15 pm

  • (SLFNR) - Otherwise known as Stay Late For No Reason, you’re not even getting paid for this nonsense-but you look good leaving last don’t you-until someone sees the logs and you’ve been on facebook the whole time.


  • Wolfan - October 27, 2009 at 12:06 pm

  • Don’t forget Developed By Marketing (DBM). I’m in the middle of a project right now where the head of marketing is in charge of all development. I’m told to add “AJAX” to my project, when I explain that there is no need for AJAX I’m told to add it anyways because that’s what they client wants.


  • Craig Cook - October 30, 2009 at 7:29 am

  • Date Driven Development (DDD) – A senior manager in the company arbitrarily pulls a date out of his arse (normally the Friday just before an import golfing holiday) for when he needs a report. This means that a load of developers need to jump though hoops to write a system to produce the report, whilst having to continually deal with requirement changes and middle management customers that can’t actually make a decision about anything. When the system is delivered a week late, the senior manager is already playing golf and doesn’t care anymore, so all the developers are sacked.


  • Never Ending Project (NEP) - November 17, 2009 at 2:23 pm

  • This happens to be my favorite method, and one I have seen implemented most often. Surprisingly, high-powered project management ninjas using the most stringent, industry best practices standards of design often fail to bring software projects to that elusive champaign-popping moment when everyone high-fives and celebrates… It rarely happens (on time and on budget) despite everyone’s best efforts. One of my project managers even resorted to issuing fatwahs upon other team members to inspire their efforts without any affect!

    I believe the reason for this and the other methods you described can be more easily illustrated when compared to that of large construction project analogies… With constructing a bridge, building a dam, or designing a sky-scraper, the base design characteristics have already been defined. Specifications for I-Beams, cables, electrical wiring, concrete, etc. don’t require any thought or meetings on how much weight a particular cables can hold… with software, everything is in play, and the tools we use are ever changing. The day that software design and project management methodologies work without issue and can easily be learned and implemented will be the day that our industry’s workforce shrinks by 75%. this is why small development shops will be around for a long time.


  • Slave - December 8, 2009 at 3:21 am

  • GMSBDM - Gangster Management and Sadistic Boss Driven Methodology.

    How else would you name a methodology, in which your boss forces you to develop a saturday and sunday, without having a real deadline for Monday, and when you arrive at 11:10 a.m. instead of 11:00 a.m on sunday, after having worked the whole week+saturday, you receive this mail message ? :

    From: Andreas Graae
    Sent: 14 September 2008 11:49
    To: Developer-Slave Nr 1.
    Subject: Today

    Slave nr.1,

    When you are late, it means that your colleagues have to stay longer and that makes me absolutely furious.
    Especially since I had this conversation with slave nr.2. yesterday I find it very offensive that you repeat it today.

    I want to make it absolutely clear that this is the last time you are late, ever. I don’t want to have this conversation ever again.

    If you disagree with the above or if you have any questions regarding the above please let me know right now.

    Andreas Graae
    CTO


  • James Carlson - December 10, 2009 at 11:04 am

  • This is a great article–I totally agree that this should become part of the typical computer science courses worldwide. It will become required reading for any development team I form or work with henceforth!


  • Jacob Dunphy - December 10, 2009 at 11:34 am

  • You’re also missing Fate Driven Development. Why write tests, when you can count on the will of fate? Also related, Prayer Driven Development.


  • Matthew - December 10, 2009 at 12:01 pm

  • And this is how we came to know and love IE 6, 7 and 8.


  • blue - December 10, 2009 at 1:24 pm

  • every one is negative. what about

    Spiritual Inspired Collaboration (SIC)

    A group of people working together peacefully to achieve a goal that is based on the enlightenment of humanity. There are many paths to greatness and together we can traverse them all.


  • verec - December 10, 2009 at 1:49 pm

  • Our process is Well Rounded: We’re cutting all the corners …


  • rvangeldrop - December 10, 2009 at 2:15 pm

  • Hot Air Planning Approach (HAPA):
    The management team is in a hot air balloon and doesn’t rely on anything else but gut feeling on when the project will be landing. As a result they always overpromise, which causes deadlines to slip dramatically.

    Meanwhile, the developers, who are on the ground are shouting as loud as they can even though it is pointless, get blamed for not being able to deliver in time.


  • frank - December 10, 2009 at 2:31 pm

  • TGBP development, This Gotta Be Possible, yeah right


  • Tom Brennan - December 10, 2009 at 4:00 pm

  • Clap Clap Clap Clap – Great write up and the comments are really funny.


  • Gav - December 10, 2009 at 5:47 pm

  • Go F**k Yourself Development – GFYD: When everything is going well, it’s the last sprint… then some one from marketing gets involved. They umm and arrr for a while, and then announce that everything on the project needs to change, with changes outlined on a 20 slide powerpoint presentation with arrows pointing to “things” with vague and/or irrelevant issues like “text needs to be bigger” (HOW F***ING BIG!) and all you can really do is shout “GO F**K YOUR SELF” in your head and shout “AAAAAAARGH” for long periods of time every time they enter a meeting room.


  • Tiago Pinto - December 10, 2009 at 9:02 pm

  • Did you ever seen WADD (What’s Around Driven Development), or as others call it IWOFT (I Want One Of Those), in action?
    Usually this happens when the client wants something he saw on Facebook, Twitter or any other website he (or his wife) uses. Also, it’s very common to see “This project is something like thiscoolwebsite.com but better”.


  • Sachin - December 10, 2009 at 9:12 pm

  • The first thing (ADD) is cent percent true and I have experienced it….at least I think every one can relate one or more with them….


  • Patrick - December 11, 2009 at 1:10 am

  • **FDD** Family Driven Development. Management adding their spouse, son/daughter, nephew/niece, etc to the development process generating wonderfull **Family Driven Development Discussions**.


  • jcdickinson - December 11, 2009 at 5:32 am

  • Bug Driven Development (BDD). Write code and features like crazy; once the features are complete push the product out the door and let the public do your QA.


  • jcdickinson - December 11, 2009 at 5:35 am

  • Sales Centric Development (SCD). Sell a product and/or features that do not exist; then code like crazy to follow through on your promises.


  • William Sharp - December 11, 2009 at 7:18 am

  • I have suffered from ADD for years! This post is an absolute classic! It ranks up there with The Office and Office Space! Thanks for the cathertic content!


  • Jen McCown - December 11, 2009 at 7:57 am

  • This is the best blog, ever, on anything, in the history of everything…probably because I’ve worked under all five development models.


  • Jon Kern - December 11, 2009 at 9:59 am

  • Don’t forget “Management By Magazine” (or email). This is when your boss decides to tell the team to do something because they read about in the (airline) magazine that sounded cool.


  • Don - December 11, 2009 at 2:35 pm

  • Re-invent The Wheel Development (RTWD) – Because the lead developer is utterly incompetent and un-willing to learn new methods of development, he writes his own…everything.

    This method of development is motivated by a total lack of understanding of a technology platform augmented by re-inventing the wheel to implement things the platform already handles quite well.

    Don’t understand String.Compare? Write your own. Source control system a mystery? Write your own. And while your at it, stuff it into a 2500 line method call.


  • Erik - December 13, 2009 at 9:23 am

  • YAID – You’re An Idiot Development. A process whereby a senior person hides his incompetence behind name-calling of his junior people thereby stifling all opposing design ideas resulting in 20 year-old designs and demotivated staff.


  • Dada Mungo - December 14, 2009 at 2:05 am

  • How about MNBD – Management Knows Better Development. This is when management insist on having a say on everything, whether or not it lies in their domain of expertise or responsibility. Another name for this could be DBI (Development by Interference).


  • Matches Malone - December 14, 2009 at 10:08 am

  • I’m thinking there’s something relating to laying off people that don’t appear to be working for the company 24/7, when in reality, there is some loyalty left. Has happened to me on more than one occasion, but this isn’t about me :)

    Layoff Imagined Deadweight Disorder? :)


  • JohnnyTwoShoes - December 17, 2009 at 1:52 pm

  • I’m a software developer too (databases), and we’ve used the name BSD, Banana Software Development.

    Why banana, you may ask?

    Ripes at the customer’s site.


  • Yehoram - December 18, 2009 at 1:05 pm

  • This one can be common – RDD
    Resume Driven Development.


  • Dean - January 2, 2010 at 8:28 am

  • It’s easy to be a follower that complains. Instead, why not step up to the plate? If you know better, then prove it. If you only think you know better, but really don’t, then stay a complainer.


  • My starred Google Reader items about PL research and other things « Sagar Sunkle's Blog - January 10, 2010 at 3:10 am

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


  • Kosten - January 13, 2010 at 2:33 am

  • What about these:

    We’ve Got It Already (WGIA) / We Promise Anything Developers Will Do It (WPADWDI) – is where managers present features that are not done as something that’s finished for ages to be superior to competition and leave the magic to developers

    Keep ‘em Uninformed (KEU) / Blur As Much As You Can (BAMAYC) – is where boss tries to blur the task by giving the developer only algorithmic instructions and keeps the relations to himself so the director cannot fire him because he’s the only one who knows how the project works. This has additional drawback when someone asks the developer if he’s done that project module, he does not know because he only knows the logic not the module name and relations

    Leave It For Then There’s Plenty Of Time (LIFTTPOT) – there’s always a time to check your blog, personal e-mail, twitter, facebook and then start coding when boss enters the office or the customer complaints about schedule skew

    You Meant It This Way? (YMITW) – Is when a management or boss chooses the easiest way, which is most of the time not what the customer wanted, just because the customer wasn’t enough specific about his needs

    I Tried It, It Just Worked (ITIIJW) – is when developer types loose code and claims that on his PC everything worked right

    :)


  • G.B. - January 14, 2010 at 8:55 am

  • Somebody-Will-Fix-It-Development (SWFID): I don’t really know how it works, I copy and paste something that works in a similar way, and if the compiler doesn’t complain, it’s good enough.


  • Asshole Driven development « TheLoneGunMan - January 16, 2010 at 9:06 am

  • [...] Softwareentwicklung und so anderes Zeug. Da dies in der Praxis meist nicht so gemacht wird gibt es hier eine paar Alternativen. Bei uns [...]


  • Leo - January 20, 2010 at 7:08 am

  • Recently came through Attack of the Clowns Methodology, variation of brainstorm approach. Instead of team of experts project manager is exposed to every end-customer and they have full rights to make their idiotic suggestions every time they have some absurd idea in their mindless heads. Imagine to be woken up at 4 am just because one of those clowns have “brilliant” half-baked thought how to help to run the project. Looks like over-speeding bus driven by band of lunatics who is struggling between themselves to grab the wheel.


  • Lyall - February 1, 2010 at 3:48 pm

  • SCD – Scope Creep Development

    Where the scope, as decided by everyone, but the developers, gradually expands to consume all available, resources, continuing to expand until SCPC (Scope Creep Project Collapse) occurs.


  • Asterix! - February 2, 2010 at 2:02 am

  • Here is one that happens at my office..” Develop it..We Will Change it Anyway – DI/WWCA” and the most irritating one!!!


Scott's Bestselling Books
  • Confessions of a
    Public Speaker
  • Provocative and funny secrets from a veteran speaker, you'll laugh as you learn.
  • Buy now at Amazon Book Details
  • The Myths of Innovation
  • The classic bestseller on how amazing lessons from the past can help you innovate today.
  • Buy now at Amazon Book Details
  • Making Things Happen
  • The classic and bestselling handbook for any project leader, packed with tactics and stories.
  • Buy now at Amazon Book Details
Photos from Recent Events (view flickr stream)

You're reading Scott Berkun, All rights reserved unless noted. You can subscribe here Blog RSS Comments (RSS)