New technology is rarely the right choice
"Boring” solutions win more often
This is “Effective Delivery” — a newsletter from The Software House about improving software delivery through smarter IT team organization.
It was created by our senior technologists who’ve seen how strategic team management raises delivery performance by 20-40%.
TL;DR
New technology introduces risk you rarely need,
Conference inspiration without critical thinking does real damage,
Your framework choice must meet functional and non-functional requirements,
“Boring” technology wins because it is predictable and maintainable.
Contents
Hey!
Aleksander here.
Every week, a new framework appears.
And you still have a React frontend, an Express backend, and a PostgreSQL database.
Very often, that is a good decision.
Choosing technology for a project is not simple.
On one hand, you need to ship a working application quickly.
On the other hand, you will maintain it for a long time afterward.
And rewriting a system almost always turns out to be too expensive.
In this issue, I want to show why “boring” technologies win, where resume-driven development begins, and how to make technology decisions you will not regret six months after going live.
Resume-driven development
You know the drill.
You go to a conference, you hear about an interesting technology such as GraphQL or DDD, and you come back inspired.
There is nothing wrong with that on its own.
The problem starts when someone comes back and wants to turn the project upside down right away, just to use a new approach, without deeper analysis and without checking whether it actually fits.
It often ends in disappointment.
The fact that something worked for a speaker does not mean it will work in a different context.
Presentations show solutions under specific conditions, with a specific team, problem, and set of constraints.
This pattern is fairly common, and it can cause damage when IT teams start building systems not based on real requirements, but on the desire to try a new tool.
That is where it is easy to enter the territory of resume-driven development.
Resume-driven development means making technology decisions not because the project needs them, but because they look good on a resume.
Context matters
When designing systems, IT teams often look at how large companies do it.
IT teams copy microservices, multiple technologies, specialized databases, and custom solutions for specific problems.
The problem is that most applications do not operate at that scale.
In practice, 90% of applications do not need separate technologies for every use case.
That level of complexity translates to higher development and maintenance costs, not real value for the user.
Large companies such as Netflix, Uber, and Bolt did not start with elaborate architectures.
They started with simple monoliths and straightforward applications.
The goal was to test the idea, acquire users, and understand the problem.
Only later, when real traffic, data, and specific bottlenecks appeared, did they choose more specialized tools.
They did not make that shift before the scale demanded it.
Why you shouldn’t switch
Inspiration from large companies or conference novelties is not inherently wrong.
The problem starts when IT teams apply such inspiration without asking whether a given technology actually fits the project, the team, and the real business needs.
Technology should not be evaluated through the lens of whether it is “cool.”
The starting point should be concrete criteria that help you make an informed decision.
Old beats new
When you have worked with a given technology for a long time, you know its flaws, limitations, and problems.
Paradoxically, those known flaws are often the reason why sticking with proven technology is the right call.
Proven technologies are stable, predictable, and you know how to configure and maintain them in production.
New solutions carry the risk of surprises.
Immature tooling, gaps in the ecosystem, and problems that only surface in a real production environment are all things you cannot predict in advance.
🇵🇱 Z Polski? Wpadnij na mój własny Substack i sprawdź jak rozkminiam inne strategiczne decyzje projektowe.
The right competencies
You might be a Vue fan, but if your team has experience mostly in React, proposing to rewrite the application in Vue will probably not go as smoothly as it seems.
The team will need time to learn the new framework, and then more time to reach the same level of efficiency as before.
The person who proposes a new technology takes on responsibility for onboarding the rest of the team, quality control, and problem-solving.
It is doable, but it is neither fast nor free.
Maintenance overhead
Every technology, whether a framework, library, or platform, carries an operational overhead that must be factored in before making a decision.
Deploying a simple container and connecting it to a database is a different thing from maintaining a Kubernetes cluster in production.
At conferences, you often hear that Kubernetes provides high availability, scalability, and system resilience.
That is true, but those benefits have a price.
Functional requirements first
Every technology must meet the functional and non-functional requirements of the application.
If the project requires good SEO, you will not reach for plain React.
If specific security standards or regulations apply, those narrow the possible choice of tools.
For me, requirements are always the starting point, and they naturally limit the range of technology decisions.
Put reliability first
Not every project requires the same approach to technology.
Business-critical applications should rely on proven, mature technologies.
Choosing innovative solutions means taking on responsibility for their stability, maintenance, and any problems in production.
Smaller supporting applications give more room for experimentation.
They are good candidates for testing new tools in a limited scope and seeing whether they deliver in practice.
Private projects can serve as a playground where you learn new technologies without any business risk.
Technology decisions must always be made in the context of the specific application and its future maintenance.
Do not let FOMO or resume-driven development drive them.
“Boring” technology does not win because it is perfect.
It wins because it is predictable and maintainable.
Next time
Adam Polak believes AI-generated code is becoming the biggest delivery blocker ever.
It’s dirt-cheap and faulty by design.
He’ll share his tactics for staying safe around it.
Most subscribers haven’t seen this
Published with a smirk by The Software House
Twarda 18, Warsaw, Poland
tsh.io →
 | A guest post by
|