Modern Software Development Methodologies

18 Mar 2010

If you are a software professional, you would have come across various software development models / frameworks – such as Waterfall, Spiral, Agile, Extreme Programming, Test Driven Development, etc.. There are some interesting ‘models’ which you would have experienced in your projects, but forgot to call it with a name.

Scott Berkun has posted a few such well-known development models, and there are a few hundred comments added by software professionals from there experience. Following are few of selected such methods.

Even if you are not from a software field, you may be working in project oriented organisation. The some of the following software development methodologies may well apply to you all.

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. Asshole breaks them and people follow anyway. In worst case Mr. Asshole might be a completely non technical person who has positional power (i.e. Boss).

Management by Panic (MP) methodology

Every management action is predicated by an “emergency” change. Usually executed in the absence of planning.

Budget Driven Development (BDD)
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 and exhausted developers.

Management by Crisis (MBC) / Development by Crisis (DBC)
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.

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 propagated by weak and ham-fisted Project Managers.

NADD (Not Allowed To Do Development)
With all sorts of ‘methodologies’ and rules touted by analysts or PMs, it’s surprising any development is actually done. Managers can be heroes in the meetings and not in development, so they like to keep on talking in meetings eating up valuable time of developers. Then they will expect developers to stay late to do coding!

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.

Completely Redundant Application Process (CRAP)
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.

Just One More Feature Outside Schedule (JOMFOS)

Regardless how high the pressure, how tight the schedule, or how late the project – JOMFOS product managers can always find something strategic (read: we have to land this contract) and groundbreaking (read: this one customer think it is clever) that not only breaks the current design, but also has to be squeezed in before the unmoving (yeah, right) release date.

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.

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.

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.

Must Use Specific Technology Development (MUSTP)
In many projects 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?”

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

Next Shiny Thing Development (NSTD)

When your development focus changes every time your boss comes back from a tech conference.

Developed By Marketing (DBM)
Project where the head of marketing is in charge of all development. I’m told to add “AJAX” to my project, when I explain that there is no need for AJAX I’m told to add it anyways because that’s what they client wants.

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!

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.

Learned Helplessness Development
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.

And, finally this is the result of any of the above methodologies,

IWIWSE mode (I Wish I Was Somewhere Else)
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 existence.

References:
- Asshole driven development
- Management_anti-patterns
- Dev Lanka


Related Posts
- The Myth about Money
- Boss Vs Leader
- Love your work, but not the company
- Never fall into the trap of 'Flexible Hours' !
- The political reading of American Idol
- Trear drop of capitalism - A case study
- Smart Employee in Open Economy

Bookmark and Share Related Posts with Thumbnails

3 comments:

Anonymous said...

elama ela kiri....

Anonymous said...

Thanks for this, but i was looking for some good literature

Anonymous said...

LOL this describes in exact detail how the last company I worked at operated!

 
 
 

Adaderana Sinhala

ලංකා සයිබර් නිවුස්

Defence.lk

 
Copyright © Lanka Rising