Selecting a new technology stack can be a big strategic advantage to your company, however it is critical to be careful while doing so, because picking up a wrong technology can even put complete project at risk.
First step towards choosing the right Technology Stack is to determine if we need a newer technology stack or going with an existing technology will be a better option.
Let’s first compare the benefits of an older vs newer technology stack. –
Benefits of an old Technology Stack –
A technology, which has been around for years, gets enough time to become mature over the time. A wide range of users use it for different requirements and in different business scenarios, which over the time exposes most of the flaws and loopholes. This gives enough opportunity for developers to find and fix many issues. Also more time means more iterations of development, which means technology has got more time to add features and support more business scenarios.
Benefits of a new Technology Stack –
The primary reason of going with a new technology is usually two major benefits,
1) It has been redesigned from the scratch with consideration to all the known issues with existing technologies. Old technology may try to patch issues with fixes and tweaks but will never be as strong as a new created framework which has altogether avoided those loopholes from the beginning.
2) Technical ecosystem evolves way faster than any other sector. So a technology which is few years old may not be the most compatible and future proof product to go with. A new technology usually future proof you for coming few years.
What all to consider while choosing a new Technology Stack –
Now coming back to the original point, while choosing a new technology, you will find claims stating, how this new technology is faster, better, lighter, and shinier. Making it very easy to fall for it, by thinking that using this new technology will solve most of your application issues which are coming with current software products.
However it is not always correct and there are major points which must be investigated carefully. Lets see the key points you should check before choosing a new technology stack –
1) Limitations:
This is the prime risk with any new technology, considering that it has not been used widely. This may throw some serious limitations along the way. Initial reviews and evaluations may not be thorough enough to expose these caveats.
Example –
a) A NoSQL database which appears to be faster than the existing SQL DB in initial comparisons, but midway through implementation you realize that it is as slow as a SQL DB after adding Business Logic in the queries.
b) Midway through implementation you realize that debugging a new programming language is nightmare compared to the old programming language you were using.
How To handle –
In order to avoid such situations it is important to go through few actual test cases specially using your actual business scenarios. Doing some initial POC can be very helpful in revealing such unknown risks. However be careful to make POCs based on your real business requirements.
2) Skillset enhancement:
A very new technology means you will find, no to very few people with hands on experience with the technology. So account for the cost and time required in initial training. You may consider to hire trained people, however hiring new team members with a lesser known technical skill-set has its own challenges and limitations.
Example-
You started your project with AngularJS but you don’t have enough trained people in team. Now would you train your existing team members on Angular or would you consider hiring new team members who already have hands on experience with Angular. If you provide training to existing team, how much time would it take for them to be ready to start the development work. On the other hand, if you got recruitment, how much time recruitment will take, and then you will need to train new members on project details.
How to handle-
Best approach is to try to take a balance approach based on existing knowledge level of your team members. Consider points like – How many people are good with learning new technology, how soon you can expect your best learners to start working with a new technology, how soon you can hire someone, can you create a mix of people in team. A long term strategy can be to encourage your team members to keep learning new technologies. So when the actual need comes, you have at-least few people available to lead the situation.
3) Compatibility with the existing architecture:
Verify if the new technology will be able to integrate with your existing architecture, framework and infrastructure. Sometimes new technology is not compatible with existing infrastructure, and you may require to buy new servers or plan for some work around to make it work with existing framework. This can directly impact project timelines, budget and resource requirements.
Example –
1) Will your new application module be able to interact with your existing ESB Server.
2) Does this new technology support your existing SQL Server version ?
3) Will your existing servers be able to take load of this new application, or you will require to acquire new hardware?
How to handle –
Factor this point well in advance to avoid later surprises, this can be done by doing some detailed check about all the integration requirements. Sometimes solution may be as simple as creating a wrapper or adapter to connect with your existing framework.
4) Technical support :
Software development teams try to use a new technology sometimes at a very early stage (sometimes as early as Beta phase). This means getting technical support can be a big challenge. Very few resources will be available on internet or on forums during such early phase. This increases the risk of getting development team stuck with technical issues.
Remember bugs and serious technical challenges are the reality of software development process. It is advisable to check what support channels are available for the technology you are choosing.
Example –
There were many teams which decided to use WPF when it was in Beta phase (I was part of one such team). Finding any help on any issue was almost impossible. Microsoft had left many bugs in WPF even after final release, this caused a lot of delay and confusion during the development phase.
How to handle –
Going too early with a new technology comes with these challenges. See if you can wait some time before boarding the boat. The earliest support you can get is directly from the development team of the framework itself. Usually they are active on their official support forums.
5) Stability of the Technology:
Usually new software frameworks follow a rapid software release cycle. Since technology stack is still maturing, they prefer to follow a quicker inspection and adaptation cycle. A quickly evolving technology poses a big challenge in coping up with the changes.
Rework may be require to keep the product up to date with the latest framework version. Otherwise you risk your product to be left on an island of old version, with known issues and security risks.
The trick here is to check the future road-map of the technology before choosing it, and prepare a strategy to be in sync with it.
6) Possible short life span of the Technology:
This is not a very common risk but its impact is so significant that its worth considering. It has been seen time to time that a new framework is abandoned by its parent company during its development. Usually this happens in a situation of –
A) After not seeing a significant traction
B) Due to merger with some other company
C) Strategic change in the product line
D) Some major inherent design flaw in the technology.
This a rare but unfortunate situation and you can hardly do anything to avoid it. The only due diligence you can do is to check the reputation of the company behind the technology. Usually big companies follow a graceful path even if they decide to kill a product.
Selecting a new technology can be tricky, however if you keep the basics correct and consider the above mentioned points, you can avoid major risks. Do not try to pick a technology stack in rush, remember that spending some extra time during the process of selecting a technology can save a lot of time and effort at later phases.