As seen on http://www.scottberkun.com/blog/2007/asshole-driven-development/
Acronym Driven Development (ADD)…Have you had enough of all the xDD acronyms that have emerged over the last couple of years? Do you already know all about Responsibility-Driven Development, Test-Driven Development, Behavior-Driven Development, Domain-Driven Development and Model-Driv…
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.
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.
Learned Helplessness Development — in which team members have been beaten down for so long that they assume that no matter what they do, they’ll suffer because of it. It’s the result of frequent and random negative reinforcement combined with infrequent and random positive reinforcement.
Not allowed to do development (NADD) - somewhat similar to CYAE. No actual development is tolerated by the development team. Everyone with any technical knowledge at all is at least 3 levels too low on the corporate ladder to be allowed to make even trivial decisions, and any initiative by individuals is a sign developers have too much time on there hands - meaning they are either poorly managed and ignoring whatever it is the bosses boss thinks they do, or they can be laid off. Developers are occasionally fed poorly written specs, not allowed to ask questions, and yelled at for “being late” before they are given the 6 signature sign off they need to write a single line of code.
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.
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.
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?
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.
Copy/Paste/Modify Patterns (CPM for short).
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.
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.
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.
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.
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.
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.
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.
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.
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.
BQAD (Blame the QA Development) or QASD (QA s*cks Development) - An advanced CYAE. This is a kind of development where you blame on QA for everything. If your company has incomplete specs, and you are a messy coder who likes to skip reviews and not write any unit tests - then just relax and try the BAQD or QASD….
It works for sure..
MSBoC Model structure by organisation chart. The software and or/database model is based on origanisation or organisations producing/using it regardless of the soundness of the design or needed duplicated data/functionality.
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
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.
WSIAD (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.
GTMGTFM (Get The Money, Get The Fucking Money!) methodology usually makes good use of the ADD approach.
NKWYWUYSI (Not Knowing What You Want Until You See It) Design: We get this one all the time. Management know they want something but they’re not quite sure what - so there is no design spec. What they want then gets poorly communicated down to the dev team, who then produce their version of what they think Management wants, and then the project enters the NESD (Never Ending Story Development) phase.
Closely related to “Duct-tape Driven Design” are similar patchwork style methodologies LHFD (Low Hanging Fruit Development) and PLRA (Path of Least Resistance Architecture).
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 its highlights involve training your eventual replacement and pretending that they don’t suck so as to be a “team player”.
Mao Model of Management. (MMM) Thats where you’re never told what you should be doing, you’re only told what you shouldn’t be doing. Generally you are told what you shouldn’t be doing only after you’ve started doing it.
DBC - Development By Crisis (Management By Crisis).
Everything is a Crisis. Every task, you have to “Drop everything” and work all night long! Woe to the developer that mentions that the user acceptance testing doesn’t even begin for another 2 months… Everything is a disaster.
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.
TMCD - Too many chiefs, not enough Indians. When you have 6 bosses each trying to take the project in different directions. At least one boss wants you to figure out why his laptop keeps locking up and another wants you to come to his house to setup the interweb. The others require you to attend at least one 3 hour long conference call with them per week.
TPD - The process development. When the process of the project becomes more important than the project itself. No work can be done without a TPS report. See Sigma Six for further details.
ITD - It’s Tuesday development. Feature freeze and requirement specifications? Hell no. Today we are changing out the requirement so much that we are effectively working on a different project. Why? Because it’s Tuesday.
YBG IBG “You will be gone, I’ll be gone” so who cares.
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.
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.
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.
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.
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.
All of the above 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.)
“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!)
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.
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).
*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.
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.
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.
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.
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).
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.
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. :)
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.
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.
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?
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
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.
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.
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.
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.
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.
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”
PMW: Project Management Warlordism where project managers act like turf-centric warlords …
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!!!!!
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.
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!
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.
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.
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
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.
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 functionality throughout the system.
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.
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.
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.
CNP - Chuck Norris Process : a developper works on a project. Then another takes it in charge. Glups! he realises that his colleague worked applying the NoDDD - No Design Driven Development. Wooo, there’s only one solution : do what Chuck Norris would do. So, he has to take the code, kick it, send it into orbit, and re-develop all the project again. Thanks Chuck. You’re welcome!
BFSDD: Big Fucking Snowball Driven Development. Early in the 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.
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.
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.
L24-DD: Learning in 24 Hours Driven Development. Teach you self books users.. =)
Deadbeat Baseball Coach Development: Shows up in the bottom of the 9th for the first time and if things are satisfactory he’s your best friend, if not, you’re a worthless programmer who develops applications that serve no purpose to humanity.
Damn the Man Development (DTMD): Coding done to bypass the established constraints and policies over what it would take to comply.
NDD - Nobody Driven Development. A bit chaotic one.
NOD - Never Optimize Development
Firefighter Development…As all your development time is spent putting out fires created by the previous development team who created the project using the SCREW’EM Development.
Crash Driven Development CDD or Iterative Crash Driven Development ICDD where you work endlessly fixing software development with zero specs and daily manager intervention.
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.
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 :-)
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.
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.
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).
PAPPPAD: Pulling Agile out of our Asses Development. 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.
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.
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” ;-)
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.
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.
FMBDD- Fuck My Boss Driven Development, 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!
· Elegant Code » *DA : Buzzword Driven and Oriented Architecture, Design, and Development - July 1st, 2007 at 9:06 pm
[...] (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. [...]