Asshole-driven development
[Since this was originally posted commenters have added 100+ addition methods – see the comments below. There’s more commentary on reddit]
The software industry might be the world’s greatest breeding ground for new systems of management. From Agile, to Extreme Programming , to Test Driven Development (TDD), the acronyms and frameworks keep piling up. Why?
Some say it’s immaturity: that software is still a young industry and all the change is the path to some true fundamentals. Others say it’s because software people like making things up and can’t help themselves. Well I say this: if we’re going to have dozens of models we may as well have some that are honest, however cynical, to what’s really going on much of the time. There is a happy list of these I’m sure, but this is the cynical one.
Asshole-Driven development (ADD) – Any team where the biggest jerk makes all the big decisions is asshole driven development. All wisdom, logic or process goes out the window when Mr. Asshole is in the room, doing whatever idiotic, selfish thing he thinks is best. There may rules and processes, but Mr. A breaks them and people follow anyway.
Cognitive Dissonance development (CDD) – In any organization where there are two or more divergent beliefs on how software should be made. The tension between those beliefs, as it’s fought out in various meetings and individual decisions by players on both sides, defines the project more than any individual belief itself.
Cover Your Ass Engineering (CYAE) – The driving force behind most individual efforts is to make sure than when the shit hits the fan, they are not to blame.
Development By Denial (DBD) – Everybody pretends there is a method for what’s being done, and that things are going ok, when in reality, things are a mess and the process is on the floor. The worse things get, the more people depend on their denial of what’s really happening, or their isolation in their own small part of the project, to survive.
Get Me Promoted Methodology (GMPM) – People write code and design things to increase their visibility, satisfy their boss’s whims, and accelerate their path to a raise or the corner office no matter how far outside of stated goals their efforts go. This includes allowing disasters to happen so people can be heroes, writing hacks that look great in the short term but crumble after the individual has moved on, and focusing more on the surface of work than its value.
I’m sure you’ve seen other unspoken methods at work – what are they?
Please add to the over 200 reader suggested methods in the comments.
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?
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.
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.
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.
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.
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.
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.
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?
Also: I totally forgot about management anti-patterns, which will be of interest to those entertained by this thread.
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”
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.
Or how about a dev shop with all of the above? :)
Ehi, don’t forget also the Copy/Paste/Modify Patterns (CPM for short).
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.
Politics-oriented software development:
http://www.kuro5hin.org/story/2005/1/28/32622/4244
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.
How could you leave out the NIH (not invented here) methodology?
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.
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.
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.
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.
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.
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.
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.
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.
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.
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.
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.
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.
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.
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.
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.
ILTCASISTLCE: I’m Leaving The Company Anyway, So I’ll Structure This Like Crap Engineering.
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.
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.
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?
nice post. This reading this is working like a reverse vent for me
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..
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.
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.
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.
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.
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
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/
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?
Cool post… Most of the things I have encountered in day to day life over past 10 years of software development are covered.
GTMGTFM (Get The Money, Get The Fucking Money!) methodology usually makes good use of the ADD approach.
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.
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.
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.
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.
Closely related to “Duct-tape Driven Design” are similar patchwork style methodologies LHFD (Low Hanging Fruit Development) and PLRA (Path of Least Resistance Architecture).
This article (with compiled-in comments) should be in Wikipedia!
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”.
Man you are some angry developers.
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.
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.
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.
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.
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.
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.
YBG IBG “You will be gone, I’ll be gone” so who cares.