- Senior Developer Shiny Object Syndrome (noun) ˈsiːniə dɪˈvɛləpə ˈʃaɪni ˈɒbʤɪkt ˈsɪndrəʊm
- A condition wherein a developer, usually far too proud of their own abilities, uses technology and/or tools inappropriate for the need just to show off his abilities. (Condition is almost exclusive to males.)
Software development – no matter the platform, no matter the delivery, no matter the use – is difficult. (Yes, there are varying degrees; I’m sticking to the general case here. Bear with me.) Building a solution takes a lot of planning, architecting, writing, testing, and review. None of it comes easily.
This is, of course, how we ended up with pre-built software packages to avoid the classic “reinventing the wheel” problem – someone does it once, and we get the benefit of using it. If someone does it well, that package could be used (in one form or another) for literal decades.
If a software package isn’t well maintained or fails to address changes in industries, hardware updates, platform introductions, critical vulnerabilities, or the dreaded delivery paradigm shift (think cloud computing), someone else will inevitably think: “I can do that better”.
This is how we’ve ended up with multiple operating systems, numerous different pieces of software, along with many duplications of functionality, rushes to beat someone else to market, and a litany of people who read one article and decide that a newly-released piece of software is the best thing ever and that’s what’s going to be used!
This shouldn’t be a bad thing, really. Iteration such as this is how we improve: we see an example of something that exists, we see its strengths and its flaws, we establish a new path forward. This has been done for centuries, the process largely responsible for our modern era. (And if it weren’t for stupid software patents, we might actually be further ahead.)
Where SDSOS comes into effect is when someone selects a new programming language, library or framework, or tool because they heard it was the newest, neatest thing and they want to use it on the project. Almost invariably without understanding the impact to the development process, never mind the maintenance.
I’m the opposite. Over many years, I’ve learned to approach projects from the perspective of maintenance: how much trouble will this be to keep up-to-date? I’ve come to this position as a result of having many different projects continue for many years, all of which need updating, repairs, and improvements. And all of that takes time; time is money, so more time means more expensive, and everyone hates expensive.
That makes me the equivalent of the stick-in-the-mud. I want tried-and-true, not shiny and new. Because shiny and new often comes with the caveat: not feature complete, not completely tested, not well documented, and (this is for you devs out there) not enough information on Stack Overflow or Reddit to get you out of a hole.
These shiny things are toys, being used by people without the experience to know if that toy is going to be a problem. Sadly, a lot of these toys come with the promise of “easier”, which at the outset is often true. Take NodeJS for example – you can set up quite a bit of a Node project by using Node’s extensive dependencies, saving you a heap of time in development. However, taking on too many dependencies quickly becomes Sisyphean because you can never escape the constant software update.
It’s like a snowy mountainside – it looks beautiful, but underneath are many different layers of snow and ice, and all it takes is one tap in the wrong place for it to turn into a 200 km/h avalanche. The only way to avoid the disaster is to maintain that mountainside, triggering little blasts to keep the snow from getting too unstable.
The same goes for software: if you can’t maintain it, you get a disaster. It can be a simple as changing a build script (which, IYKYK, not that simple), or rewriting an entire module because it simply cannot work in the environment any longer.
I urge all of you who wish to own the title “Senior” to watch this in your own work. Don’t be “that guy” (yes, again, almost exclusively men who do this) and push for something you don’t fully understand, knowing you’re walking away at the end of the project. We’ll know who you are – Git never forgets.
Take the time to studying it on your own, or at the very least, outside of an active project. Understand the ins and outs, understand how to update and maintain it, understand its risks and not just its rewards. When you do bring it your project, you’ll be much more like the sage wizard with the answer to the riddle, and not the pirate who just seeks fortune and glory.
