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 never saw any of the infamous:
1. DNFL (Drunk Now – Fix Later) approach.
2. HDS (Happy Debugging Suckers) technique.
3. OGCJM (Only God Can Judge Me) development.
and my personal favorite:
4. LSIYCKUTTMDHE (Let’s See If You Can Keep Up This Time My Dear Hardware Engineers) religion.
This is nice :) I detailed another form of development Google Driven Development http://chandermani.blogspot.in/2013/01/google-driven-development-gdd.html
WPD – Whim Driven Development – For personal projects…where I am the asshole – I prefer to call it “whim driven development” – http://www.paulkerrison.co.uk/random/whim-driven-development-wdd
DRTBD : Don’t Rock The Boat Development.
Satisfies all those senior developers that are looking forward to retirement and don’t want to develop on anything that was not tried and proved during the 90’s, the decade in which their latest mindset update took place.
Man those old fogey developers are so stupid. I’m glad like you we’re mostly rid of them.
HDD: Hormone Driven Development: Development done by some young guys who think they know it all (evident by posts like that from the little tyke OldCoot). These HDD kids lack social skills and tend to write convoluted, over engineered code hoping to impress everybody (even the old guys they despise). Instead of taking advantage of being mentored by older developers who have been writing code since these young dummies were still in their mother’s ovaries, they are arrogant self-promoting, blowhards who are TOO STUPID to know they suck as a developers. They are too immature to understand that the older guys have met and overcome challenges in their careers unknown and unfathomable to these young maggots. Sometimes these young ‘uns are even promoted into an ADD position for a short term until they fail and are removed. Go ahead now kids – think of something clever and condescending to write in a reply now.
Every word is true. The ignorant, immature, untrue remark above proves it. If you want a real laugh, go to the KODI/XBMC forums and read all the little troll-girl replies from the kiddie coders to people who raise legitimate issues about their absolutely crappy, buggy app. Not having ANY experience or knowledge or historical perspective, these underachieving, over-praised, narcissistic little wankers have nothing to offer and can only break down into name-calling, finger-pointing, little temper tantrums. That’s why, increasingly, we have crappy buggy apps in general, coming from big companies. The programming ‘gene pool’ is drying up as older, more mature, more intelligent, more experienced programmers are displaced by ‘cheap help’.
“these… narcissistic little wankers have nothing to offer and can only break down into name-calling”
This would seem to put you in the same boat with them.
“This would seem to put you in the same boat with them.”
Not really. I’m just responding to an obvious agist. Agism is the new racism, the new sexism, the new homophobia. It deprives its victims of the respect and dignity they have earned, and of a means of making a decent living. You wouldn’t criticize a black person for responding to a racist remark, so why do criticize this?
Not every old coder is terribly wise. Some of them are just entrenched in bad habits and really do refuse to learn anything new.
For as many anecdotes as you have of some young hothead with bug-ridden app because he didn’t understand the rudiments of testing, or problems caused by someone haphazardly abusing all the latest features of C++14 or Boost just because he could, the younger guys have anecdotes about an older programmer who refused to learn how to use version control, or who insisted that Kerninghan & Ritchie said everything that needs to be said already, or who used his authority to prevent needed performance upgrades because they involved adopting a new paradigm he didn’t want to learn.
I’ve experienced all of those, by the way.
That sounds exactly like me…
Hey, uhh, how about you drop a link to your repos before you start claiming that you’re qualified to mentor a rock. Talk is cheap… you should know the rest of the quote.
FBD – Fear Based Development
Nothing ever changes because every decision that might make things better is instantly poo-pooed by senior developers who all cite the same apocryphal story from the nineties about how they tried that and it is expensive and doesn’t work regardless of how far the rest of the software industry has come with the technology or tools since then.
FBD Real world example #1: when considering upgrading to git (from dimensions) the idea that git could do automatic merges of any kind was literally and loudly laughed at
FBD Real World Example #2: when considering doing any level of automated testing anywhere in the building an apocryphal story from the nineties is always cited as other senior developers get nostalgic and nod and the idea dies a quick and painless death.
Follow up:
Sedimentary Team Building: the submitter of the disruptive/innovative/modern idea gets so frustrated (or even hurt) by having their ideas repeatedly and summarily dismissed that they leave the team or the company leaving the FBD’ers to ‘settle’ back to doing the work the way it’s meant to be done.
Fear-based development runs much deeper than tool sets. It’s also why refactoring is forbidden, even to the point of fixing inaccuracies in comments.
That whooshing noise right before you blew up was the brutally obvious sarcasm in the post you responded to zipping right over your head.
I humbly submit the following:
Color Driven Design (CCD): the code doesn’t matter, as long as it’t he right shade of blue. If you work on the backend you don’t have restrictions, since it doesn’t matter.
“accent based engineering”, where the guy with the German accent clearly has the greatest engineering skills.
“half cost procurement strategy”, where it’s great as long as we can do it for half the cost.
Can confirm.
Am German, have greatest engineering skills.
I love the “accent based engineering”. I use to work extensively with our home office in Switzerland. They ‘obviously’ were the best developers in the organization because all bugs were created in the US.
EDD – Error Driven Development. Cubicle dwellers are constantly putting out fires, chasing bugs, fixing bugs, debugging, patching bad code, breaking data type interfaces, all because of short-sighted managers who love golf more than software quality. Combined with silly rules like “be here by 8am” regardless of 60 hour weeks and saturdays/sundays. EDD mimicks natural control systems found in nature.
Throw It At The Wall Development (TIATWD).
Satisfies the CEO who suffers from true ADD (Attention Deficit Disorder) and keeps shareholders confident that the company is releasing one great feature after another. A key to successful TIATWD is that that the company cannot be bothered to observe what happens to the wall because it is too busy slinging the next pile.
Most interesting spelling of tight wad I’ve ever seen
ISRAEDD ::= IntelliSense R# Alter+Enter Driven Developement
Press Ctrl+Space choose something and, press Alt+Enter to add reference no matter which layer, choose a method and think “If it is public then it is OK”.
WHD = Work Hours Development
A development process where developers make things work in dirtiest possible way just to mark their work hours for the bosses that they did something.
HDD = Hacker driven development
It is important to do it, no matter how you did it. Any type of constraints, weather from a language, design or methodology is refused. If it is not performing well, throw more hardware at it.
And of course the less lines of code you use the better, specially of you are using a cool feature from your scripting language the does some sort of magic, regardless of the fact that you are the only one who understand this code, and even you will not understand this code when you read it 3 month from the day you wrote it.
SMDD- Smothering Hen Driven Development
-An addendum to ADD, where the asshole smothers you by sitting beside you all day like a hen does with her eggs and suggests a plethora of ideas that will render maximum counter-productivity and clobber any progress back to the stone age. This methodology is further supplemented by CTRL+Z Driven Development, when you follow the asshole’s advice but scraps it after spending much time, effort, and personal life once the client finds out you did something outrageously not in the design.
RIPS – Reward Incompetence Punish Success
In an ADD-driven environment, the most incompetent get rewarded by the more incompetent, for being members of the same ‘Stupid Club’. The successful, competent developers are punished for making the incompetent managers and their little kiss-asses look bad. Their goal is to force the competents out so the incompetents can continue unexposed and unchallenged.
They follow the AABC rule–‘A’ people hire ‘A’ people while ‘B’ people hire ‘C’ people. Eventually there are only ‘C’ developers being lead by ‘B’ or ‘C’ managers.
So who hire B’s? Where do they come from?
Overengineering Driven Development (ODD)
Best way to create great Vaporware. The stable Version of ODD 1.0 coming soon!! …Really! …Sure!
Any moment now… I can almost see the release blog now..
[JAFA] Just A Few Alterations Development – consists of a team of at least 100 software engineers spending at least 5 years on fixing up, bootstrapping and building around a quick piece of software made by 5 people for 6 months.
Buen articulo
[SUF] Soviet Union Factory methodology – documentation is not existent, one dev doesn’t know what other one is doing or what an overall project should do. Given small and specific tasks they stumble in the code blindly. Communication is kept to zero. Code is full of methods who perform exact same function. Patterns are either non existent or there’s as much of them as there’s developers rendering any effort to keep structure clean useless. Management thinks project is too big to fail
Sweet post – Id like to add the Defcon Prioritization Technique (DPT). Where there always are multiple levels of artificial urgency to make sure the everyone keep busy and on their toes.
This is genius, I have seen this so many times. This technique involves long discussions about which level of artificial urgency to apply.
TBOD- total brain overflow development …
if u develop things nobody understand …but it works fine.
Lol CYAE
BDD- Beer driven development. Write as much code as fast as possible while black out drunk, then attempt to integrate while sober.
UDD – uber-framework driven development.
Your employer paid money for this piece of trash uber-framework and all the time spent is essentially spent on preventing the thing go self-aware and take over the universe…
Johnny Cash Development (JCD):
I like to practice development driven by Johnny Cash. It’s where I waste a day trying to understand your worthless code while humming to the tune of “God’s Gonna Cut You Down”
How about HFDD – Hay Fork Driven Development – shovel as much hay on the fire as quickly as possible…and just keep doing that until whenever. AKA – SLOCDD where developers are rewarded for producing source lines of code (the only true empirical measurement of delivering value).
Or DicDD – Dictator Driven Development – where the technology is dictated from up on high as well as the timeline and the design, and you are really just here to paint the walls. Related to CMDD (Code Monkey Driven Development) or CCDD (Cookie Cutter Driven Development) or H2NDD (Hammer to Nail Driven Development) where every problem is a nail and there is a silver bullet that was just sold to someone somewhere up there that can be used on every problem (which are all nails because we have this new hammer).
Says who, liar?!
I’ve a few for you, probably duplicating one or two of the 500-odd ones already here:
* SalesIdiot Driven Development (SIDD)
Where, in flagrant violation of the correct procedures, a maverick salesdroid has sold something that doesn’t exist, probably can’t exist, or would take an eternity to make exist, it’s the company’s BIGGEST BREAK EVER, and must be done next week to exacting specifications already agreed with the customer. By the salesdroid. Alone. Given the deal value, the CEO’s reluctantly had to support it. Off you go, then. Fully working prototype by – um – Thursday work for you?
(BTW, most salesfolk know to discuss and negotiate with Engineering before making commitments. These fine, upstanding and honourable people never come onto developers’ radars. Sadly the small minority that are SalesIdiots do, and give the whole profession – which pays everyone’s wages – a bad name.)
* Innovation-Driven Development (IDD)
Everything you ever knew – everything you read about only last week as the Next Big Thing – is sooo yesterday. We’re going to refactor the project to use Gurgle.js and the Glorp framework. Yes, I know, it’s only two weeks to release. Yes, I know, Gurgle’s in first alpha, and Glorp’s on early preview. But we can do this, people!
* Wheel-Reinvention-Driven Development (WRIDD)
MySQL can’t hack it, and doesn’t support an obscure feature that we probably don’t need anyway. PostgreSQL had a bug in the last release. So. We’re going to write our own database, because we can do in two weeks what Oracle, MySQL/MariaDB and PostgreSQL couldn’t manage in a decade or three.
Oh yes. Seen SIDD SO MANY times.
I like to call the first one GDD (Golf Driven Development). Chief Exec plays a few holes with big cheese at prospective client company, during which big cheese hints at a sale if a certain feature exists. Chief Exec responds “what a coincidence: that’s in our next release!” and seals the deal. Dev team then has to implement it by yesterday, with the added bonus that they can’t ask the prospective client to clarify exactly what they wanted the feature to do because as far as he’s concerned it’s already implemented.
PDD – Panic Driven Development
Reacting quickly to sales requirements with no planning, tests or wider business value.
“We’re gonna lose this customer unless we add in this customer specific thing they forgot to tell us about!”
KTCD – Kick The Can Development
All important design and architecture decisions are delayed to finish a couple “critical” features in the next two weeks. In two weeks, six more features will be deemed “critical” and four more weeks added to project, but still no time for design or architecture. Continue process for the next 2 years, then scrap the steaming mess for a new technology that promises to rewrite the entire project in just 6 weeks.
Repeat process with new technology.
CIMTD – Console is my therapist development
The mode of development when the dev is not very confident and logs variables every 2 lines. Console is their therapist and they tell it everything.
I95%DD (It’s 95% done development). (For any US East Coast familiar also jesting on the joy of driving on I-95)
When business gets so frustrated with IT timelines (because the developers are dealing with multiple of the aforementioned methodologies) that they tape and glue something together with whatever is on hand(Access, Excel, VBA, macros, SharePoint, etc) and call it an application and then turn it over to IT saying it’s 95% complete and just needs to be ‘productionalized’.. IT then has to take the realistically 10% proof of failure (POF), reverse engineer requirements, design and code some level of first phase while being harassed daily (hourly?) by an entry level project manager who maintains that business almost made it on little budget and just a few weeks (or months) of effort.
EIMI: Everything is Most Important
Whatever is new get top priority (too), so everything gets started, hardly anything finished.
SDD – Sales Driven Development – Sales sold a non-existent solution to a huge client and now the developers have to make it work somehow.
CDD: Contrary Driven Development
Wherein programming suggestions are presented in contrary to clear best practices because the presenter is butt-hurt that they didn’t introduce the solution.
SOOP – Stack Overflow Oriented Programming
When you really haven’t got a clue about what you’re doing but have located Stack Overflow.
LCDLC – Loose Coupling DeadLine Caring – when your PO can’t be bothered with progress and specifications but suddenly wants to change everything and add a plethora of new shit two weeks before delivery.
You need to learn how to spell things.
It’s “asshole-driven” development. When you’re combining multiple words to make one descriptive term, you do so with hyphens.
And there’s no word-count limit.
This post has had well over 100k+ pageviews and you’re the first person to point this out. Thanks for mentioning it.
BLDD – Backdoor Layoffs Driven Development
where fear of a down-round and management by accountants drive the enterprise to seek ways to reduce there engineering headcount (damn expensive engineers, with their equity packages, market rate salaries, and paid time off, why can’t they all be like sales bros working on commission?) without actually “firing” anyone.
the primary methodology of this development style is tearing up the entire development roadmap and replacing it with moving targets, which will be moved daily, and then demanding unpaid overtime commitments from the entire engineering team (70 hour work weeks! we promise its “temporary”) to make those targets.
Despair Driven Development (DDD)
– It’s clear the project/company is going to fail anyway, so hack on anything you want, it doesn’t really matter.
IGA (I’m Gone Anyway) Methodology.
Where you know that you’ll leave the company by the end of the month and don’t care about anything.
ARDD: Ayn Rand Driven Development.
Every class does only what’s best for itself with no thought or concern given to any other class, any objects created are held on to privately forever and any object that needs something is considered a parasite.
TDD (timecard driven development) – hack for a while. commit at 4 PM. you may not be able to separate features, but you can back code out to the most recent “runs” commit before the rollback you need!
From hackernews
TDD: Test Deficit Disorder
Every person in the team knows he/she *should* be testing, but since nothing is covered, no one goes first
Haha! Nice, I wrote something like this but for managers. Check it out: https://www.techtum.eu/god-said-let-there-be-management.html
Hammer Driven Development (HDD) – Hit it with a hammer until it works. If it doesnt work, get a bigger hammer. Get into production via jack hammer.
FDD – Faith Driven Development.
(write or copy code from stack overflow code and pray to god that it works.) I have seen this being done all the time. Or, write something and test it out to see what it does.
Dude… That’s not even development. That’s theft / plagiarism of code!
You see that happening in your department state it to your manager and human resources, that person is no programmer.
While copy paste is a no no, compared to managers who don’t do any work at all and escape into meetings if you propose them something that requires just five minutes of work from them this is also bad. Should rename some managers Jira pushers no knowledge only task assigners
I thought stack-overflow Was the Asshole-driven development… most of the people that respond there are jackasses. They close and cry about every question, good questions, questions I wouldn’t have seen jackasses so proud they know they answer to while refusing to answer because it’s beneath them, had I not turned to google for an answer myself. I should ask stack-overflow how to permanently block stack-overflow from google search results since they complain about questions more than they answer them.
Yeah, I tend to agree with you on that. Probably the worst of the Stack Overflow that I’ve encountered are the jerks of the Ubuntu area.
I would get into fights with the mods. I would attempt to help someone and I would answer to the best of my knowledge in regards to the given question. Then on occasion, the question was asked incorrectly and I had to ask for more information to better serve the person that needed help. My answer was blocked the second time and the mods had it out with me. I said, it’s not my fault that someone couldn’t articulate what it is they needed help with and that the the mod was overacting. I reminded him, “Ubuntu is Linux for Humans” and to remember that fact, that includes fielding questions and giving answers. That humans are not perfect, therefore they will on occasion not ask the right question to get the right answer for their problem to be resolved.
I just wanted to choke those jerks at Canonical, Ltd., they were the programmers of the said package that user was having trouble with. I said to the mod, if you’re the coder behind it, answer him, don’t leave him hanging like that. Of course, I found out who it was who was asking the question and went in IRC to help the user out. It turns, he was so frustrated with Canonical, Ltd. (the creators of Ubuntu and it’s associated desktops) he went to Fedora Linux after a year. I ran into that user again that needed help on another package, did the stint through IRC and everything is peachy for said user now.
It’s really interesting when you look at Stack Overflow, as a whole, how many people supposedly have answers but just razz people instead of answering the damn question. Those are the people the mods should banned and kick off of S.O. and not people like me, that want to help and go the extra mile. Bunch of prima donna assholes on there for sure. They should rename that site to Troll Overflow.
Just add -site:stackoverflow.com to your search.
javascript closure -site:stackoverflow.com
Try it! :)
RDD – Resume driven development – When you choose tech because it will look good on your Resume
SD – Salmon Development – Swim upstream for weeks just to get F*cked
Mushroom Development – Keep them in the dark and feed them Sh*t
Gee, this reminds me of FOSS projects, like, oh; kernel.org (Linux kernel development) [Salmon Development]
I had a good chuckle when I read this post, I’ve (unfortunately) been in almost every scenario of development teams listed up above. DBD is the only one I haven’t professionally been involved with, thankfully.
Great article!
This is so spot on it deserves to be printed and nailed to the wall for everyone to be seen.
POTA : Pulled Out Of Thin Air – who knows where that idea came from, but its the one we ended up doing….
Budget Oriented Development by Turatti:
Not “We want that, how much does it cost?”
Instead “What can we realistically build with the available budget?”
Set the right questions to avoid delusional thinking.
I had a good chuckle when I read this post, I’ve (unfortunately) been in almost every scenario of development teams listed up above.
This entails specs loosely given by someone who doesn’t really know what they want. Typically such specs are given by middle management types who are often stubborn to admit they have no idea how you do what you do. Ambiguously phrased descriptions are used to describe a solution to a problem that their boss is pressuring them to solve.