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.
I cant help but keep laughing. When i think i want to add something, its already there said by someeone. Great Post!
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
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”
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
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…
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.
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.
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.
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.
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.
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.
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.
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.
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!”
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.
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.
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!
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.
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.
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?
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.
Management By Panic (MP) methodology. Every management action is predicated by an “emergency” change. Usually executed in the absence of planning.
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.
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”.
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.
IFMIMBG (It’s From Microsoft, It Must Be Good) The opposite of ABM, probably occurs way more often than ABM too.
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
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…
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.
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.
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.
This is hilarious! Thank you all for putting into words what has caused me endless nights of unrest! ADD hahahaha….
Hello,
And where about the L24-DD: Learning in 24 Hours Driven Development.
Teach you self books users.. =)
RTBADNM: READING THE BLOG AND DOING NOTHING METHODOLOGY
this is what all of us are doing here
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!
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.
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.
Damn the Man Development (DTMD): Coding done to bypass the established constraints and policies over what it would take to comply.
WHISKEY methodology: Why the Hell Isn’t Someone Koding Everything Yet?
Great list…
YOOOOOOOW…..
WOW…
Asshole Driven development (ADD) is exactly what I am doin rite now… (>_
NDD – Nobody Driven Development. A bit chaotic one.
NOD – Never Optimize Development ( .Net & Java development paradigm? ;) )
Tim
http://gtd-tools.com
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.
some of the most creative and imaginative minds are on this page, I have enjoyed most parts of it
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.