My team has been working on web applications and digital products for over two years now and we’ve learned a lot about making the right decisions when it comes to choosing technology.
When your technology choice is more important than ever, but the ecosystem more complex than ever, how do you decide what to use?
Well, with plenty of experience in making both the right and wrong technology choices, there are three questions I like to ask:
Is the technology fit for purpose?
Making sure your application is future proof is near impossible – the rate technology changes at is too fast. Where AngularJS was once the hot ticket, then came ReactJS, and who knows what’s next. The question to ask in this situation is: is the technology fit for purpose?
Imagine you need a live chat module in your application. The key to a chat module is making it fast and responsive. This means that you need to pick frontend and backend technologies that target performance in the area that your feature needs to support.
A general purpose, jack of all trades, server-side application framework such as Symfony can be made performant but in most cases, it will prove too slow and may lack helpful features such as Websockets. You could certainly implement a chat server in Symfony, repeatedly having the browser request any updates, but this will more than likely be slow, heavy and difficult to scale.
A non-blocking technology such as the Express framework on NodeJS does things differently. Rather than load lots of features into memory that aren’t required, you can write small, tight services that do one thing and do it well – thus providing a much more responsive feature.
This is a prime example of choosing a technology that is fit for purpose. As long as you can justify its use, and that’s fit for purpose then you’re on the right track.
Do your research and due diligence, the technology you choose might not be the most exciting to work with but if it’s fit for purpose then it’s by all account the right choice.
What’s my team’s technical capability?
Working in a team gives you so much flexibility when it comes to choosing which technologies to use. But, bear in mind that your application will only ever be as good as your team’s technical capability.
Pair programming is a great way to share knowledge and avoid development bottlenecks
If your lead developer begins building a key module in EmberJS then falls sick for two weeks, what happens to your application’s development — will your junior developer able to take the lead with confidence, are they capable?
If you’re fortunate enough to be working in a team then perhaps assess what your team’s technical strengths are and the potential risk involved in choosing a less familiar technology. Business continuity is an important factor, if progress is halted because of a particular skill-set dependence then that can be detrimental to the development of your application, and more importantly the business.
Whether it’s a hack-day or being mentored by a co-worker, there are plenty of ways to learn new technologies — knowledge sharing will help to avoid any bottlenecks in development. This article on encouraging knowledge sharing at your company gives you a handful of basic pointers to get you started.
Will the technology allow my application to scale?
What happens when your user base increases from 100 to 100,000 users?
Scalability leans more towards the overall design and architecture of your application rather than the technology used, per se.
However, how efficiently your application can scale will depend on the technology that has been chosen. Knowing how a particular technology will perform if things change can make or break for your application (and potentially your business).
Maintaining performance is crucial as you scale your user base
For example, one of our main applications includes a people picker module built in AngularJS. It loads a list of people and allows you to paginate, filter and search for the people you want. For the vast majority of users, this means a very fast and responsive experience, as the results would update instantly as you typed a query.
One problem… it doesn’t scale. Add another 100,000 people to search and the slowdown is very noticeable because of the delay in updates while typing a search term. In the end, we decided to replace the module with something that allowed us to scale and run multiple concurrent queries — we chose Google’s systems development language Go. A necessary but timely expense to the business.
Research and development in the form of rapid prototyping can prove to be a cost-efficient way of testing the feasibility of a particular technology and its use within your application. Dedicating time for research and development has helped us stay abreast of how the latest technology can assist with maximizing each of our application’s potential.
With the myriad of options out there, making the right technology choice is no easy task, and when you’re working in one of the most exciting industry’s in the world, the temptation to experiment can be unforgiving. However, giving yourself and your team the opportunity to sense-check your technology choice really can mean make or break your application’s success. Make sure you choose wisely.