Project Naming

Funky or Practical?

Whenever I've started work on a new project I've had an introduction along these lines:

Wizard feeds into Pluto, which then re-values. It broadcasts changes that are picked up by Puma and recorded by Halo.

but what they really mean is something like:

The Market-data System feeds into the Trade Calculation Engine, which then re-values. It broadcasts changes that are picked up by the Trade Display GUI and recorded by the Audit system.

The IT industry seems to have a peculiar habit of giving projects names that have no relation to what they actually do. Perhaps we feel the need to make a dull system sound more interesting ("We can make the accounts receivable project exciting by calling it Skydive") and this is fine if you have only one system. I deal with architectures that have dozens of subsystems and this can be a real problem by adding to the learning curve and confusing newcomers.

There is an argument that a system's name shouldn't have meaning as the scope of the system will probably grow and change throughout its life. If a project has a very specific name such as "stock-option pricer" it will be inaccurate once you add the ability to price bond-options. A few years down the line it could actually be much confusing than calling it Pluto.

It would be nice if you could change the name of a project/system but this can be very hard. Not because you can't re-factor code and change configuration but because of funding, politics and the users familiarity.

What is your preferred technique for naming projects and systems? Something funky, something meaningful or a compromise? If you are attending the user group meeting this Tuesday you can share your craziest project name with me!

Update - It's been suggested to me that in a SOA system you should name a service very exactly and when the name no longer matches then it's probably time to introduce a new service. Neat!

About the author

Robert Annett Robert works in financial services and has spent many years creating and maintaining trading systems. He knows far more about low latency data systems and garbage collection than is good for anyone. He likes to think of himself as a pragmatist who loves technology but uses what's appropriate rather than what's cool.

When not pouring over data connections or tormenting interviewees with circular reference questions, Robert can be found locked in his shed with an impressive collection of woodworking tools.

E-mail : robert.annett at

Re: Project Naming

I favour the safe-but-boring (cop out) tactic of non-descript acronyms. That way you can juggle the name a bit when the requirements flip and TRS moprphs from a Trade Reconciliation System into a sTock Rotation and Supply platform. Or whatever.

I like names for iterations though ("next week will be the Jupiter release"). Gives you the flexibility of re-ordering production releases without the version numbering getting confused.

Re: Project Naming

It's a tricky one, I think you're in trouble which ever way you go. It is however not impossible to do both. I once worked on "Project Vampire" which was all about stakeholder pensions...

Re: Project Naming

From my past how about 'Project Hattie' because it had a bloody big back end - you have to be of a certain age to appreciate that one

Re: Project Naming

I once named a project KERBCRaWL, safe in the knowledge that it was unlikely to be an acronym in general use.

I've found this problem usually crops up after the first iteration of a codebase. You've picked your package name and then someone in sales gets to see the user interface and suggests a new name for the product. You can't win!

Having names like Badger, Pluto and Wombat is at least a shallow learning curve. The problem arises when you can't form a glossary around the names because the system functions aren't clear (ie, a new service should have been introduced)!

Re: Project Naming

Not exactly addressing the problem but ...

My current project has two names. One for the business and what they want to call/market the project as and one for the dev team (which is generally more frivolous) which doesn't need to change as the whims of the business do.

This of course makes the architect's job that much more complicated so not much help....

Add a comment Send a TrackBack