Wednesday, September 12, 2007

Little Known Development Drivers

Most of us are familiar with multiple development concepts. Examples such as Test Driven Development (TDD) or Behavior Driven Development (BDD) are fine methods to write code under, but are far from the only drivers of development. I would like to go over a few of my favorite methods for pushing software development in an organization - equally as valid, if not slightly esoteric.

Resume Driven Development

RDD is not a term I coined - but if you want to credit me I shan't argue (it'll be our little secret). This is the style of development that is best represented by flowchart:


This kind of development is overly represented by technical consultants - especially the kind that travel. Perhaps this is due to the position in which they are placed: singular technical experts surrounded by non-technical clients. This is a recipe for minor abuse, if not outright exploitation.

However, despite the obvious drawbacks of such unmitigated trust (the most glaring: the technology suggested may not necessarily be the best for solving the business problem at hand), there are places where such development style is not so bad. I've seen this actually work in larger companies where innovation moves at the speed that fingernails grow, it helps to have someone who always wants to push to the newest technology - someone eager, interested and alert (even if only to thicken up a balding resume). The pestle of corporate politics will eventually grind this person down - but for the short term, some sliver of vicissitude might just make it out of the mortar unscathed.

Annoyance Driven Development

ADD is aptly acronymic
This only works if your developers actually get annoyed - the higher-strung the better. I've known people who are so tight they fart in octaves once reserved for calling dogs and shattering wine-flutes, and are perfect specimens of ADD. It works well for people who are kept up at night worrying that your XML-based configuration is substandard and could be more easily managed if replaced by YAML. Or cannot take a shower without imagining how cool their company's perfectly working system of web services would be replaced by CXF+Camel+Terracotta on EC2.

This is my style, and the style of most developers I call friends. When it works, it kicks ass - with only slight social drawbacks. But when it does not work it is disastrous... some people just plain don't care.

Contract Driven Development

Features or technology chosen because they prolong the life of a contract. Someone I know works for a (major, yet unnamed) consulting company. They charge an arm and a leg (then steal an ear and your nose while you sleep) before they are done with most contracts. It's a murky world where they reside, secretly ramping up the cost of healthcare in unseen ways, for example, convincing a hospital board that they need bed-side game consoles that must interact with the rest of the hospital system. Why? Because it would take forever to develop (who knows what they tell their clients) - and there is a good chance it will never be delivered anyway. However, the client won't know that until it has wasted hundreds of thousands of dollars in the attempt. Caveat emptor, I guess. Except the client will never tell anyone that they wasted money - leaving the consulting company free to hunt for their next contract. I doubt this is what Adam Smith had in mind.

I really cannot find anything positive to say about this kind of development. Hiring consultants is always a crap-shoot. Except for Amentra - these guys rule (I swear, I don't get kickbacks :) - they are bloodhounds for finding really smart people).

1 comment:

Learn PHP said...

informative tutorial. thanks. keep them coming.