This post ponders on a few of the key considerations that are often overlooked before choosing languages and frameworks to implement an new project.
Perhaps one of the single biggest changes seen by those who have been constructing web applications over the last 10-15 years is the emergence and wide-scale adoption of web application frameworks. Back when I started commercial software development in 2001 there was very little to choose from. Popular PHP frameworks such as Symfony and Zend were a few years away from initial release and it took another 9 years for the first version of Laravel to emerge. Even the ever-popular Spring framework wasn’t to surface for another year.
All jokes aside though, this is really important stuff. Technical debt can be crippling and the further the project gets down the road with more features added you’ll become more and more locked in to your technology choices – much as developers always talk about “we’ll address that when we rewrite version 2” the reality is at least one constraint of either time or funds usually prohibits this.
Here is a list of some of the biggest mistakes I see businesses making when choosing technologies.
what happens when you need to add development resources to the team to support the project, or the first developers move on? I’ve seen this really cripple projects – for example – up in the Durham/Teesside area, trying to grow a reasonably sized team of Ruby on Rails developers might be a struggle. Because they’re so thin on the ground you’ll have to persuade developers from outside the area to relocate, allow developers from other areas to work remotely or (at an even higher cost) cross-train developers from other disciplines.From this point of view in the North East of England backend technologies such as .Net/C# or PHP seem the best bet – with Java/nodeJS coming in next. For front end, Angular and React seem to be best.
as anyone who has had to migrate a project from Angular 1 can attest, it can be a pain when your framework upgrades fundamentally between major versions causing breaking changes that will in turn trigger lots of development work just to keep apace.It’s always a good idea to build in some time in your development schedule for framework and security updates – the major established frameworks help with this because they have well documented upgrade paths and documentation that is easy for developers to follow.
particularly back-end frameworks such as Laravel provide powerful in-built functionality for application development such as queueing and full text search which can be enabled often with little more than a few lines of code.However it’s important to remember the need to support this stuff – traditionally implementing queue and messaging systems pre-frameworks required detailed knowledge and a sound understanding of the concepts at hand.
Having the ability to switch the features on is great, until it all goes wrong in production and you can’t figure out why – having a nose around under the hood and understanding the different configuration options will pay dividends.
Rapid prototype and application development has become easier than ever before – with an abundance of of well supported tools truly stable enterprise level application functionality can be achieved with open source components.
It’s always wise to do the due-diligence up front from both a technical and business/ cost perspective – and also factor in time for the strategy and implementation to replace technologies as the project grows.