If there’s one thing that will excite most software developers, it’s the LATEST SHINY DOOHICKEY.
When I was first starting out my professional software development career, it was only a few years after the world wide web was born, so anything internet-related was the hot new shiny.
Microsoft’s Active Server Pages (ASP) technology came out around the same time and gave developers a powerful programming tool that allowed Microsoft developers to use their Visual Basic programming language knowledge to write sophisticated web application code that could live on a web server.
Sun Microsystems was making a lot of waves around the same time as Microsoft, and they introduced a hot new programming language called Java and a server-side web programming technology similar to Microsoft’s ASP technology, named Java Server Pages (JSP).
Adobe developed a hot new client-side programming language technology called Flash, which was one of the first plug-ins available for internet web browsers.
Let’s see, what else was going on? Oh, there was the introduction of XML, a universal new data format.
Oh and web services. Oh, and let’s not forget AJAX. And COM. COM+. DCOM. Python, Ruby, the list goes on an on.
And of course, it wasn’t just hot new technology. There were also lots of new programming methodologies and concepts that completed the new technology.
Things like design patterns. And extreme programming. Pair programming. Agile. Test Driven Development.
It’s enough to make anybody’s head spin, but that’s the name of the game in software development.
Every software developer knows this by heart: that the only constant in technology is CHANGE.
I can only speak for myself, but it’s one of the things that keeps me in this career field… there’s always something new to learn.
And it’s important for developers to keep abreast and embracing of change. I’ve seen good developers suffer through layoffs because their technical or business domain skills were no longer needed or required.
I had to learn this lesson the hard way myself. You’re only as valuable as the skills and knowledge deemed valuable by the company or organization who employs you. And in the field of technology, that means your skills will always need refreshing, it’s just that simple.
I certainly wasn’t complaining about it. I happened to be lucky enough to start my programming career at a time when the internet and all the exciting technologies that spawned from the internet, were there for the taking, in a giant digital sandbox for developers to learn.
Every day was a brand new learning experience … how many other jobs can you think of where that happens?
That said, here’s the conundrum we software developers have to acknowledge and come to grips with: The Shiny Syndrome Problem.
The Shiny Syndrome Problem
It took me the longest time to realize that the line of thinking “Technology drives the business requirement solution” is 100%, absolutely incorrect.
[bctt tweet=”‘Technology drives the business requirement solution’ is 100%, absolutely incorrect.” username=”profocustech”]It’s what every shiny new technology solution promises, a silver bullet that magically solves all the problems all of the predecessors have failed to solve.
It’s the same old story, every single time.
When XML was first created, it was heralded as the second coming of data formats.
It was supposed to solve the problem of different systems and applications that were formerly unable to communicate to each other.
Say company A’s IT department was built around the Microsoft technology stack. And company B’s IT department was built exclusively around the Java tech stack.
Now company A has a merger with company B and they have to integrate their systems together.
XML and web service technology came about to help completely different systems built on top of different technologies communicate with each other in the universal data format of XML.
When I first learned about XML and web services, I thought it was the end all, be all silver bullet solution for data exchange.
But it didn’t last forever. A new more lightweight data exchange format named JSON (Javascript Object Notation) has now replaced the older XML data format. Not only does it take up less memory, it’s now the de facto data exchange format for REST services, which have also replaced XML based web services.
Nothing Lasts Forever
What’s worse is when new technology dies a lonely, unsupported death.
I learned that the hard way when I pushed one of my dev managers to allow me to use Microsoft’s Silverlight plug-in technology to write an in-house web application.
Silverlight was Microsoft’s answer to Adobe’s flash scripting technology. When I first read and learned about it, I thought it sounded fantastic. It was shiny, it was new, and it seemed like it would make web applications development a first-class citizen as rich and powerful as traditional client desktop application development.
Boy, did I push hard for it. I presented my spiel to my manager, and promised the moon, if she would just allow me to follow through and adopt it for a new greenfield project in our backlog.
I’m not ashamed, I practically groveled and pleaded practically like a five-year-old, until she relented and let me develop my application with it.
Long story short, I pounded away on my keyboard until I came up with a beautiful and shiny new Silverlight web application that did exactly what I wanted it to.
And all was shiny and good, until Microsoft pulled the plug on their homegrown plug-in technology and announced they would end mainstream support for it, and no longer invest any time or resources into future versions.
I admit I didn’t see it coming. I thought Microsoft would continue supporting it forever, and I was convinced it was going to live a long and prosperous life in a web application developer’s toolbox.
Fat chance.
I certainly wasn’t happy when I first learned Microsoft was dropping their own technology.
But it taught me a powerful lesson and reinforced my belief about technology….it’s always fleeting.
And I thought technology should drive the project.
I got lured into the same shiny technology trap as many other developers before and after me.
My first mistake was to assume every shiny new technology is going to last forever.
Silverlight was also a proprietary technology created by Microsoft and not open sourced.
Proprietary technology usually doesn’t have a long shelf life. Even after twenty-something years, technologies like HTML and Javascript are still alive and well and thriving in today’s technology landscape, because they conform to open standards and widely adopted by many technology companies and vendors.
It’s not shiny and new technology, but I am confident that HTML and Javascript will be around for many more years to come.
Tried and true technology that’s withstood the test of time and lots of adoption stands a much greater chance for long-term viability and a long shelf life.
When thinking about what technology stack or programming language to adopt, tried and true will win over untested and shiny, pretty much every time.
My worse sin was letting the technology drive the project.
Technology comes and goes. But a company really doesn’t care about technology, only what business problem the technology can solve.
The Business Problem Defines the Technology
It sounds simple and logical enough, doesn’t it?
When a project is in its initial kickoff stage, the very first meeting that should happen between the project manager or product owner and the technology staff is to discuss and determine what exactly is the business problem that needs to be solved.
In that initial kick-off meeting, there really shouldn’t be any sort of discussion on what technology solution should be used.
Initial project discussions should revolve around determining what exactly is the nature of the business problem to be solved.
There will inevitably be lots of business-related questions that a developer or team of developers need to be asking the business or product owner.
Only when the developer has a good solid understanding of the business requirements should the process of picking what appropriate technology stack, programming language, framework, etc, should be selected to create the technology solution for the business problem.
And when the developer is in the process of selecting the appropriate set of technology, there should definitely be lots of thought put into picking the most appropriate technology that will withstand the test of time and give the highest chance of success.
I know, easier said than done.
But remember it’s not just you who’ll be the only software developer responsible for maintaining and enhancing that project. Chances are you’ll either move on, to another department, a different company, retire, or a whole bunch of other possibilities that end up meaning you’ll no longer be attached to the project.
You’ll want the next person who comes after you, to be able to quickly get up to speed on the codebase, one because it’s the right thing to do and two …. let’s see…what was the quote I’m thinking of?
ALWAYS CODE AS IF THE GUY WHO ENDS UP MAINTAINING YOUR CODE WILL BE A VIOLENT PSYCHOPATH WHO KNOWS WHERE YOU LIVE.
Amen.
