Asshole driven development
June 19th, 2007
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.
Add a Comment or trackback from your own site.
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.
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….
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.
[...] 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 [...]
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
[...] scottberkun.com » Blog Archive » Asshole driven development (tags: fun management) [...]
[...] scottberkun.com » Blog Archive » Asshole driven development (tags: development programming methodology management software) [...]
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..
[...] friend sent me a link to this thread. Brought a wry smile to my face without wishing to be cynical I’ve come across [...]
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.
[...] Read the original source… [...]
[...] 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 [...]
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 guy has called me out - he’s discovered my software development management style w/o ever even working for me! [...]
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.
[...] http://www.scottberkun.com/blog/2007/asshole-driven-development/ [...]
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.
Cover Your A** Development…
Tags:This is one of the funniest post I have read lately:
http://www.scottberkun.com/blog/2007/asshole-driven-development/
Scott lists (with more in the comments) the real acronyms for “real life” development methods, since the usual ones a…
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.
[...] taking the Asshole Test, now is time to know about the Asshole Driven Development and other “alternative” [...]
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.
[...] Asshole Driven Model 21 06 2007 Asshole driven development [...]
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 - To 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.
[...] I have to admit that this list more accurately decribes the real methodologies in use in many places (software or [...]
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!!!!
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.
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.
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
NST Development - Next Shiny Thing Development. When your development focus changes every time your boss comes back from a tech conference.
Obviously Scott Berkun knows too much. Black helicopters should be dispatched to his location immediately.
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.”
WAILDD - Worry About It Later Driven Development - we all have done this at some time! It usually applies to issues of performance and scaling…
VWRAH - Visions Without Resources Are Hallucinations, not only a development caveat but also a universal project truth.
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.)
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!)
[...] I saw this article on digg and it really made me laugh, I’d have to say, I have dealt with basically every one of these “design methodologies”. [...]
Hahahahaha!!! Very fun! :) I just posted an entry in my blog about ADD: http://gc.blog.br/2007/06/21/asshole-driven-development/
Besides that, congratulations for you book (Myths of Innovation). I did not read it (yet) but some friends of mine found it fantastic!
Best regards,
Guilherme
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.
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.
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).
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
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.
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.
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!”
[...] 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 [...]
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.
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!
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.
This is something I wish I had read before I left university
[...] I’ve worked at places that seemed to promote what I’ve called Flaming Potato Development, also called “Not My Problem (NMP)” Development in the comments on Scott’s Blog: [...]
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.
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.
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 :)
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).
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.
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.
[...] scottberkun.com » Blog Archive » Asshole driven development (tags: agile dev programming management software methodology development) Published by ichen June 22nd, 2007 in General [...]
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. :)
Thanks for the post and the comments. I forwarded them to our CTO for review. We have a lot of ADDs!
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.
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.
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.
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.
[...] http://www.scottberkun.com/blog/2007/asshole-driven-development/ [...]
[...] This link was sent around the office a couple of days ago, and I just couldn’t resist posting it. Very amusing. I’ve definitely witnessed a some of these methodologies in practice… http://www.scottberkun.com/blog/2007/asshole-driven-development/ [...]
Can’t Really Afford Pro’s (CRAP) - Using interns on crucial parts of important projects.
Patent Driven Development (PDD), also known as Lawyer Driven Development (LDD) - don´t need to develop selling Products, just produce enough Patents to sue.
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?
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
[...] Asshole driven development [...]
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.
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.
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…
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/
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.
Best blog post ever.
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.
[...] but I do think you should check them out if you’ve got a minute so Scott Berkun can explain these to you in detail. I would like to add, OOCDD, Out Of Control Driven Development. Unlike most methodologies, [...]
Those of us in Academia can’t forget:
TDD - Tenure Driven Development
and
ISIFD - “I Swear It’s Feasible Development”
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.
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.
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.
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…
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.
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.
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.
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”
You forgot about PMW: Project Management Warlordism where project managers act like turf-centric warlords …
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.
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…
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!!!!!
[...] 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: [...]
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.
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.
[...] 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) [...]
[...] auteur connu dans le domaine de la gestion de projet, maintenant il va être culte ! Je pense que son billet fera le tour du monde… il présente en effet quelques typologie d’équipes projet que [...]
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.
[...] This is an absolute must-read if you are involved in creating software : “Asshole Driven Development”. [...]
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.
I cant help but keep laughing. When i think i want to add something, its already there said by someeone. Great Post!
[...] 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. [...]
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.
[...] Asshole driven development [...]
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!”
[...] 21st, 2007 I don’t know whether to laugh or cry as his blog entry hits the nail directly on the head. Let’s see, currently I see the following from his [...]
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.
[...] Mehr… [...]
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!
[...] los comentarios del post se pueden encontrar 60 modelos más, [...]
[...] 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 [...]
BFSDD:
Big Fucking Snowball Driven Development. Early in the desing process, Management is warned about possible flaws in the design, but desides 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 developemnt 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.
[...] folks - apologies if you’ve had problems accessing the site. The last blog post on asshole driven development was a hit. I’ve had more traffic on that then anything I’ve written in [...]
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.
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 …
[...] a colleague of mine told me about a nice blog post that I have to share with you guys. It is about what team playing weaknesses of certain team [...]
[...] (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. [...]
[...] http://www.scottberkun.com/blog/2007/asshole-driven-development/ [...]
[...] 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) [...]
[...] http://www.scottberkun.com/blog/2007/asshole-driven-development/ Scott Berkun provides information about the new (or reinvented) systems for software project management: Asshole Driven development (ADD) , Cognitive Dissonance development (CDD), Cover Your Ass Engineering (CYAE) and many others. [...]
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…
[...] 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. [...]
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.
[...] 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 [...]
[...] Asshole driven development [...]
[...] If you use your own development process model, something that looks miles away well know models, you might read something usefull in this post Asshole driven development. [...]
[...] and process in my career… some of them are more successful or more pleasant than others. Scott Berkun crafts a great list of some of the widely-used and under discussed [...]
This is hilarious! Thank you all for putting into words what has caused me endless nights of unrest! ADD hahahaha….
Asshole Driven Development…
…
[...] This is so LOL, funny to read. Link here http://www.scottberkun.com/blog/2007/asshole-driven-development/ [...]
[...] 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! [...]
[...] Love Scott Berkun’s [...]
Hello,
And where about the L24-DD: Leaning 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.
[...] Description available here. [...]
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.
[...] http://www.scottberkun.com/blog/2007/asshole-driven-development/ [...]
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…