Developers may be pushing for a migration to the latest and greatest technology, but a technology migration is a costly endeavor. How do we know that the development team isn’t just looking to pad their resume with the latest and greatest technology? Understanding when you should re-evaluate your technology stack can be especially challenging for Managers, Product Owners, or any non-technical staff. If you’re seeing the following symptoms, it may be time to give your technology stack a good, hard look.
#1 The technology is no longer well-supported
Once a technology has been slated for deprecation, you should start planning a migration. The days of support are now numbered. Defects and security vulnerabilities will stop being patched. Waiting to migrate until a critical vulnerability is found is a recipe for disaster.
The development ecosystem may also start to die. A technology stack with a thriving ecosystem has libraries and tools that are constantly being developed and shared to solve common problems. Without this ecosystem, it’s up to your team to create these libraries when a need arises. For technologies with a large enough industry presence, companies will build SDKs for integration as it provides an easier path to trigger adoption.
#2 Developers are hard to find
This can happen for a variety of reasons. Once a technology begins to stagnate, organizations begin migrating to more modern solutions. As this migration effort snowballs, developers experienced with the technology become harder to find. Even developers with experience will refuse to work with the technology due to lack of demand.
Lesser known technologies are especially susceptible to this issue. If a team uses an up and coming technology over an established, industry-leading choice, adoption may never take off. This is why it’s important to spend time on a proper technology stack evaluation up front.
#3 Performance has reached its limit
Some technologies just can’t scale beyond a certain point, or it’s extremely cost prohibitive to do so. This is especially true with technologies that scale vertically. When you hit the wall it’s especially detrimental to product growth. Catching these limitations early and addressing them before they are impacting your end users is critical.
That said, it’s important to realize that it may not be the technology that’s to blame. It could also be that the technology has been misused. It may be necessary to rebuild portions of the application to choose more appropriate architectural patterns for the level of performance needed. Depending on the scope of changes required, a complete re-architecture can be just as costly as a technology migration. If there are any other driving reasons to change technologies, make sure to evaluate both options.
#4 Costs have spiraled out of control
Poor cloud technology stack choices upfront may lead you down a rabbit hole of expenses. What seems cheap up front while you were on the “free tier” can spiraled into exorbitant costs as the user base expands. In the best case, your margins are slowly decreasing as the user base expands. In the worst case, the cost of onboarding new users exceeds the additional revenue coming in!
Before jumping to conclusions, you should evaluate whether your cloud service usage is optimized. For example, make sure that your software is using efficient database queries that are bringing back only the data that is needed. Verify that your partition settings for any services you may be using are correct for your usage patterns. “On demand” usage billing may seem cost effective initially, but as demand increases, it may be more advantageous to setup appropriate partitioning. If your team has optimized as much as possible, it just may be time to look at other technology options.
#5 Our prototype is in production
This is a common problem with startups. An initial product idea is developed with “shoe string and paper clips” to demonstrate that the idea is feasible. Customers see the value and want the product right now! This is a great thing for a fledgling business, but can be a huge detriment to the future of your product.
Prototypes are generally developed with a technology that the team already knows or just wants to experiment with. An evaluation of whether the technology is suitable for the product is never performed. But, the technology may not be to blame! With prototypes, short cuts are taken and the quality of the code may be horrendous. If no other symptoms are present, and the technology meets the needs of your product, it may simply be necessary to spend time addressing technical debt.
#6 Your development team is slow to deliver
Has your team been underperforming? Does your team seem to check all the boxes of a high performing Agile team, but still struggles to get features out the door? It might be time to take a look at your technology stack.
If a team is constantly having to work around the technology stack to build new features, it takes a toll on the speed of delivery. As the needs of a product grow and evolve, so do the needs of the supporting technology stack. We discussed the importance of a thriving ecosystem to ensure the availability of libraries and tools, but it may just be that the chosen technology was never intended to solve your problem. This underscores why it’s so important to perform a proper technology stack evaluation up front.
So is it time to make a change?
These are only symptoms pointing to a potential problem. Before throwing the baby out with the bath water, you need to make sure the architecture of your product is well-understood and the technology stack you have is being used to its full potential. This may be a painful process and it may require bringing in an expert, but the payoff could be tremendous.
Do you need to re-evaluate your technology stack? We can help! Schedule a free consultation to find out more.