I’ve done it. I’ve been guilty of ooh shiny development. You know, those projects where you use the latest and greatest library, tool, or infrastructure not because it’s the best thing to do but because it’s the cool thing to do.
Magpie from Wikipedia Commons
magpie syndrome
An irrational affinity for shiny objects. When a highly shiny object is seen by the sufferer it often may induce a compulsive need to claim it and several minutes of staring at said object in the sun. This will later end in the sufferer pocketing the object to add to his/her collection by a sunny windowsill at home. If a shiny object is ouside of a sufferer’s grasp it will usually result in an strong, though usually short-lived obsession over it. — http://www.urbandictionary.com/define.php?term=magpie+syndrome
I’ll admit, it’s tempting. Why wouldn’t we want to use the latest and greatest technologies? We all have our reasons for doing so:
- It’s what the cool kids™ are using.
- I want to learn something new.
- The cutting edge is exciting.
- It’s great resume fodder.
- Got to stave off the boredom!
- If it’s new, it’s got to be a best practice.
- Consultant/Blogger/Mentor X says that not only it it the best way, it’s the only way.
- Well, we may need feature X which only this new tool provides, so it’s best to be prepared.
There’s definitely other reasons, but I dare say that most of them are covered above.
The problem with using the latest and greatest simply because it’s the latest and greatest is that there are usually hidden costs associated with being on the cutting edge. It can be anything from lack of documentation to bugs to integration issues. All of these increase the complexity and cost of a project.
I’ve seen a number of projects where they were over architected and over complex simply because the architect / lead developer wanted to learn a new technology or suffered in other ways from “magpie syndrome”. JMS state machines are most likely overkill for what is fundamentally a batch loader. Passing objects over a megabyte in size between components using JMS, when the database where the data resides is going to be accessed by both components, just because it is the “right thing to do because Z says so” leads to grief as well. Likewise jaxb and dom parsers are generally overkill for a single pass extraction of information from an XML file.
Jared Richardson, in Does Your Team Have STDs?, asks whether a development team has “Shiny Things Development” and provides some signs that your developers likely have STDs. He argues that in order to find a cure, you need to step back from the application and the technologies and apply a liberal dose (or three) of YAGNI.
Don’t get me wrong, there is a place for using the latest and greatest, but as developers we need to ask ourselves “Why am I using X? Are there other, simpler, ways of achieving this goal?” Antoine de Saint Exupéry, in Wind, Sand and Stars says that Perfection is achieved, not when there is nothing more to add, but when there is nothing left to take away.
By taking away until there is nothing left to take away, we can discover Just Enough Programming.
One for sorrow, two for joy;
Three for a girl, four for a boy;
Five for silver, six for gold;
Seven for a secret, never to be told;
Eight for a wish, nine for a kiss;
Ten for a bird that’s best to miss.
(from http://www.garden-birds.co.uk/birds/magpie.htm)
