I love the internet. I was idly surfing tonight for inspiration for a cool project name. I found this article. It made me laugh, but also gave me a few good ideas. I hope it brightens your day too. :)
Inventing a cool name for a software process
The exciting new trend sweeping the nation is to invent your own software development process (bonus points if it’s agile; minus points if it simply adds or subtracts practices from XP), then put it up on the web and wait for it to be cited in offhanded sentences in books and half-researched articles:
"Some examples of popular agile processes are Crystal Clear, Scrum,
Typically, the book or article then totally fails to extrapolate on the characteristics of, or differences between, the processes it’s just casually tossed off. The reason is because most of the time, the details don’t matter in the slightest. The book/article isn’t listing these processes because the author wants you to go and actually try them out, for pity’s sakes! Most likely the author just wants to make him/herself sound vaguely knowledgeable.
So, if you’re inventing your own process and you want to get it mentioned in books and articles, the most important aspect by far is to give your brainchild a cool-sounding name.
A huge mistake that some process inventors make is to start by defining the process, and then only later try to think of a name that sums up – as succinctly as in a single word or two – what the process is all about. Trust me, this never works: don’t even be tempted to try it! A name which is tailored to a predefined process will sound awkward; never quite a perfect match. It’s a bit like screwing the Marmite lid onto a jam jar by mistake.
Worse than that though, names which are based on the process tend to be way too literal. If an author is trying to think of a name which matches the process, he’ll end up with something like Feature-Driven Development, or Dynamic Systems Development Method. Yawwwn. Metaphors are a much better way to go.
The most reliable approach by far is to first think up a cool name, grab its domain name before anyone else does, and then dream up the details of the process to fit the name. And remember to choose something highly metaphorical: nothing too literal. Scrum (even though it sounds a bit too much like “scrotum”) is a good, if hairy, example of a metaphor which was obviously chosen before the process was fleshed out.
Let’s meander through a fictional example. What would be a cool name for a development process? It needs to be the sort of name that:
(a) fits into a list of other software processes;
(b) looks the part... and yet
(c) stands out from the crowd.
How about “Coal”? Not nearly good enough. It suggests latent heat, slow-burning embers, or a process which takes millions of years to complete; not to mention getting stuck beneath thousands of tons of rock strata. That doesn't sound very agile at all.
No, the ideal name must be much more dynamic, especially if it’s to sit side-by-side with the really trendy agile methods. How about “Maelstrom”? That’s more like it! It suggests movement, iterations, order emerging from chaos, that sort of thing.
Let’s try it in a list of brethren software processes in a typical half-baked article on agility:
"Agile development is taking the development world by storm! The number of projects adopting agile methods is matched only by the number of agile processes springing up to answer the flaws discovered in the last-most-recent agile process that sprang up. Some examples of agile development processes are: Scrum, Extreme Programming, ICONIX, DSDM, Maelstrom, Crystal Orange, Coal, and Adaptive Software Development."
I don’t know about you, but out of that list, Maelstrom definitely seems like the most interesting and dynamic of the processes. Its very name oozes the vital essence of agility.
So, now that we’ve got an incredibly cool name for our new process, we need to extrapolate the process itself to fit the name.
Dictionary.com defines maelstrom as:
1. A violent or turbulent situation: caught in the maelstrom of war.
2. A whirlpool of extraordinary size or violence.
Visually, this definition suggests that our new process will have much in common with Boehm’s Spiral method. The Spiral method looks like this:
Figure 1-1. The Spiral Development Process
The premise is that you start in the middle, then spin around in ever expanding circles until you understand the requirements etc. If nothing else, it could add an aerobic element to your early morning stand-up meetings.
Of course, we don’t want our new process to be too similar to the Spiral method: there must be something to distinguish it besides just the name. So what we could do is make our spiral, whoops maelstrom, start at the outside and work its way into the centre. Pure genius. Besides, that’s much more like how a maelstrom operates in real life.
So, here’s what we have so far:
Figure 1-2. The Maelstrom Development Process, In-Progress
What other characteristics of a maelstrom can we work into the process? Well, whirlpools don’t really finish in the middle: like, the water’s reached the centre so the whole mechanism just stops. That wouldn’t be very agile anyway, as in the agile world software is never done. So we need to represent the fact that each new iteration starts again at the outside edge. Again, this differentiates us from Spiral, in which one whiz around the spiral represents several iterations.
Also, a whirlpool speeds up as it nears the centre. Ships that are caught in its relentless grip, once they’ve spun around its rotating maw a couple of times, stand no chance. Their fate is sealed. So we need to reflect that in our process by stipulating that the nearer each iteration is to a release, the more resistance there will be to change. In other words, there’s no way back. This might not seem very agile, until you realise that there’ll be lots more ships (aka iterations) following quickly on behind.
Also, a whirlpool speeds up as it nears the centre. Ships that are caught in its relentless grip, once they’ve spun around its rotating maw a couple of times, stand no chance. Their fate is sealed. So we need to reflect that in our process by stipulating that the nearer each iteration is to a release, the more resistance there will be to change. In other words, there’s no way back. This might not seem very agile, until you realise that there’ll be lots more ships (aka iterations) following quickly on behind.
Evolving competency is another area that we should address. Most processes operate on the premise that as the project progresses, the team’s knowledge and understanding of both the problem and the solution will evolve. Here’s another area where we can distinguish our process.
With Maelstrom, as each release gets to the centre of the whirlpool, it essentially "drops down the plughole" (getting the product out the door) and disappears into the end-user’s hands. The programmers never get to see each release again, which makes maintenance costs non-existent: a major advantage of the Maelstrom approach.
XPers might claim to have flattened Boehm’s cost-of-change curve, but Maelstrom goes one better: it’s actually reversed the curve!
So here’s the finished process diagram – ready to be copied and pasted into countless books and articles:
Figure 1-3. The Maelstrom Development Process
Finally, to virtually guarantee the casual citing of this process in future books and articles, we could define a whole series of Maelstrom-based processes, tailored to different kinds of projects. This is similar to the Crystal series which has Crystal Clear for small projects, Crystal Orange for medium-size projects, and so on.
With Maelstrom we could have Maelstrom Teacup for tiny, 1-person projects; Maelstrom Ship-Scuttler for medium-sized projects of 15-30 people; Maelstrom Pacific for big, big projects; and the ultimate, Maelstrom Big Scary Black Hole at the Centre of the Universe, for really big, monolithic government “sink-a-thons” for which million-dollar budget overruns are more or less expected.
Hopefully this article will spur you on to develop your own development methodology. There’s a process land-grab going on right now, so there’s still time to make your mark on the software scene. Good luck with your cool new process. To get you started, here are some potential cool process names to work with. Feel free to grab one and get started extrapolating your ideal process from the metaphorical opportunities abundant in your chosen name – but remember that for the purpose of getting your process regularly cited in pointless lists, the details don’t really matter, it’s the name – and the metaphor it implies – that count:
Octopus, Tiger Bright, Archipelago, Silver Blue, Inferno, Virile, Agile Dream, Kitchen Sink, Legless, Spaghetti Monster, Vorsprung Durch Technik, Cliffhanger, Coalface, Koolaid, Lunchbox, Spirogyra, Helix, Deoxyribonucleic Acid
In fact, genetics gives us a veritable three-course dinner of potential cool process names: Chromosome, Mitosis, Metaphase, Telophase, Interphase... hey, how about "Anaphasic Software Development"?
Or we could take our cue from Scrum, and use names from team sports formations: Huck, Huddle, Lineout, Halftime Oranges, that sort of thing. If you can find a sports-related name that also sounds like a slightly rude body part, then you just might give Scrum a run for its money.
But failing that, simply choosing an offensive body part or organ is also a worthy second best.
Good luck!
