lian/Development Approaches

## Development Approaches
== Development Approaches

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.

Not My Problem (NMP) - Approach, in which all complex, complicated, expensive, or otherwise troublesome decisions/features/issues are pushed into someone else's module

Learned Helplessness Development (LHD) - 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 (ABVM) - 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. 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.

Shovel-Driven Development (SDD) - 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 (BDD) - 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.

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.

Not invented here (NIH) - not invented here

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.

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.

Idiot MBA-Driven Development (IMBADD) - 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.

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.

I Wish I Was Somewhere Else (IWIWSE) - which produces some of the most unmotivated code in existance.

Decapitated Chicken Process (DCP) - 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.

It's What They Wanted Development (IWTWD) - 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.

Visibility Driven Development (VDD) - 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.

Leave This, Do That (LTDT) - 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.

Faith-based Development (FBD) - 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.

Nerd Driven Development (NDD) - 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.

Never goes live (NGL) - 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

Not Knowing What You Want Until You See It (NKWYWUYSI) - 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.

Dead Man Walking development (DMWD) - This approach is frequently used for projects at companies who are in the process of outsourcing development jobs.

To many chiefs, not enough Indians (TMCD) - 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.

The process development (TPD) - 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.

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!!!!

Toilet Never Flushes development (NF) - 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.

Worry About It Later Driven Development (WAILDD) - we all have done this at some time! It usually applies to issues of performance and scaling...

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?

Inertia Driven Development (IDD) - 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.

Good Ole Boys Development (GOBD) - 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 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.

DIH (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.

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.

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.


#
# started by http://www.scottberkun.com/blog/2007/asshole-driven-development/
# - text found in a long forgotten screen-session of mine..
#
	== Development Approaches

	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.

	Not My Problem (NMP) - Approach, in which all complex, complicated, expensive, or otherwise troublesome decisions/features/issues are pushed into someone else's module

	Learned Helplessness Development (LHD) - 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 (ABVM) - 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. 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.

	Shovel-Driven Development (SDD) - 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 (BDD) - 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.

	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.

	Not invented here (NIH) - not invented here

	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.

	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.

	Idiot MBA-Driven Development (IMBADD) - 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.

	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.

	I Wish I Was Somewhere Else (IWIWSE) - which produces some of the most unmotivated code in existance.

	Decapitated Chicken Process (DCP) - 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.

	It's What They Wanted Development (IWTWD) - 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.

	Visibility Driven Development (VDD) - 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.

	Leave This, Do That (LTDT) - 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.

	Faith-based Development (FBD) - 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.

	Nerd Driven Development (NDD) - 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.

	Never goes live (NGL) - 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

	Not Knowing What You Want Until You See It (NKWYWUYSI) - 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.

	Dead Man Walking development (DMWD) - This approach is frequently used for projects at companies who are in the process of outsourcing development jobs.

	To many chiefs, not enough Indians (TMCD) - 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.

	The process development (TPD) - 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.

	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!!!!

	Toilet Never Flushes development (NF) - 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.

	Worry About It Later Driven Development (WAILDD) - we all have done this at some time! It usually applies to issues of performance and scaling...

	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?

	Inertia Driven Development (IDD) - 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.

	Good Ole Boys Development (GOBD) - 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 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.

	DIH (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.

	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.

	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.


	#
	# started by http://www.scottberkun.com/blog/2007/asshole-driven-development/
	# - text found in a long forgotten screen-session of mine..
	#