The Latest and Greatest Or Status Quo?! 🤔
This week, I want to talk about a topic that is important to me.
I always want to use the latest and greatest.
Why?
I want to stand on the shoulders of giants and benefit from the work others have done before me.
Why should I stick to something old when there is a faster, better, more reliable, or more maintainable alternative?
I also want to stay relevant as a software developer in the market. Why should I use Fortran or Pascal when the world has moved on?
Of course, risk is involved when using something completely new or untested. There is a reason untested machinery is never brought to a battlefield or operating room.
So, what is the right balance between choosing old and new technology? When is the right moment to try something new?
There are different models for this decision.
Introducing The Latest and Greatest
A truly experienced engineer knows exactly how the development cycle of the technology in question evolved. They may have years of experience using it in practise and they know how about future development.
(A good) management wants to have numbers to make their decision. This way, they have an excuse for the future in case the decision is wrong.
There are well-known and highly valued publications like the Gartner Hype Cycle. If a technology hits the Plateau of Productivity, we might want to consider something else.
In my opinion, the most important factors are team acceptance and skill gaps. It never works to introduce something new if the majority wants to stick with something old and vice versa.
There are conversations to be had to align all team members with the same vision—it’s a team, after all, and not just a group of individual code-producing robots.
Also, are new team members willing to adopt the old technology? Are we able to find new team members or new employees to work on that old stuff? Does it become a problem?
Or do we have enough expertise to use a new technology, or is all we know itabout s name?
Skill within the team is crucial when introducing new technology.
I had the best experience when one or two team members familiarized themselves with the new technology before introducing it to the team.
They had the chance to convince themselves if the new thing really works and what benefits they gain from applying it to the product.
And they can spread their experience with the team. It’s not an external “expert” or guru telling the team what to do - it’s their trusted team members.
Don’t underestimate the human aspect and team chemistry in this situation.
If they are already hesitant, it might be a good thing to listen to their point of view and act accordingly.
Dealing with The Status Quo Guild
But what if the company doesn’t want to introduce anything new and stays with what is true and trusted forever?
First of all, we need to figure out whether it’s a stable, reliable, industry-standard technology or if it’s stale and on a decline, or out of maintenance.
Next, we need to look at the big picture. Is there a reason why a migration or introduction of a new technology doesn’t make sense now? Is there a plan to introduce it later?
If we end up with a situation where we are convinced that continuing with the old stuff doesn’t make sense, we should start the conversation and propose a solution.
If nothing helps and there are no plans to keep up with the world spinning, jumping ship and joining another crew might be best.
PREMIUM CONTENT
