Following on from my post a few weeks ago about feature driven development in this post I am going to discuss with you the 4 genres of projects.
In literature there are primarily 4 genres of books. Crime, Romance, Sci-Fi & fantasy and horror and just like the concept of a novel can apply to a single project, these genres apply to software projects in general.
Crime driven projects are usually the result of someone having broken something. These projects are usually run by the support teams and often involve critical and major problems which require something a little more than a “quick fix”. That or they are projects which incorporate a large number of fixes spanning a multitude of problems. What they also encompass is ongoing maintainence but generally exclude refactoring legacy applications.
Romance is the ideal project, the one everybody wants to be a part of. This is where we get to play with something shiny and new, learn a whole new technology or completely redesign and replace an aging system. When we get these projects through the door, there is a fight over who is going to get to work with it but remember, even the best romance can often turn into horror as the full scope of requirements comes to light.
Sci-fi and fantasy
This is an odd kind of project which generally fits somewhere between romance and horror. We love the ideas here but dread the implementation. These projects are where the boss has demanded the moon on a stick and preferably before sundown, or more commonly, yesterday. Of course He’s dreaming if he thinks he’s going to get it but get it he will or someone is getting the chop.
Whilst these kind of projects drive us to our absolute limit we have a kind of sadistic desire to seek them out. We know that they are going to push us to the brink of insanity and then a bit further but despite the horror of the specifications we know that we too will enjoy the journey.
The last of the genres is horror. These are the projects that everybody dreads. There is no romance or even fantasy in these projects, they are dirty, gritty and quite frankly terrifying.
Generally a horror genre project involves refactoring a legacy application where we know that the moment we break out even the smallest segment of code the whole world and everything it is built on is going to fall apart and in some cases it will be weeks if not months before we find all the places we’ve broken as a result. Face it, there is always parts of the codebase that even though they are live, get used very rarely and of course there is never any form of automated testing in these areas.
Guttered or not yet guttered?
When I first mentioned the idea of this blog post to a colleague he said that he was instantly reminded of Ice Road Truckers. I’ve never seen this program but what I was told is that the truckers have 2 categories of drivers, those who have been in the gutter and those who are going to end up in the gutter. The more I think about this, the more it applies to software. Every project reaches that tipping point between being canned altogether and the threat of it being canned. It is only our skill as engineers which stand between a projects success and failure. It is down to us to estimate the scope and complexity of a project properly in order to prevent it from ending up in the gutter. A skillful driver can be sliding on 2 wheels on the ice and still recover but of you’re pulling 80,000lbs of pine on 2 wheels, on ice, with a force 9 gale building around you, you’re going over whether you like it or not and the only thing you can do is hold on for dear life and pray.