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.
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 :)
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.
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.
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
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.
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.
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
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!
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.
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 :-)
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).
I loved the CPT development above. Please tell me who posted it so I can attribute them on my site!
http://dan-thinks.blogspot.com/2008/02/new-pattern-cpt-cant-polish-turd.html
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.
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.
NADA – No Asshole Developers Allowed.
This is the worst because then we can’t join.
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).
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.
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.
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…
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.
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” ;-)
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”.
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.
You just made my day. Great list.
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.
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.
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.
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!
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.
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.
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
I loved the CPT development above. Please tell me who posted it so I can attribute them on my site!
FMB: Fuck 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!
lol.. fun article :-)
jordy, programmer of love calculator
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.
Many of our developers suffer from AHDD – Anus/Humerus Differentiation Disorder – they can’t tell their arse from their elbow.
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.
Actually for me this highly resembles to Hungarian politics – the home country of the Neumann processor’s inventor…
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
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.
(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.
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.
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.
NEP: Never Ending Project. 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.