Choose a Stack and Stick with it

Many years ago, before the advent of internet, mapping, satnav and all the other assistive technologies that we rely on, taking a long journey involved a long hard look at a road atlas and a lot of staring at signs. On one particular trip from the Stranraer ferry down to Cheshire I encountered a rather assertive traffic attendant. He certainly wasn’t part of the police force, but he seemed to think that directing traffic through the then not bypassed Dumfries gave him some sort of authority.

As I approached the junction which this attendant was managing I had a choice of two lanes, and a signpost to consider. Of course I chose one lane, and then, as I read the sign, very quickly switched to the correct lane. No sooner had I done this than the attendant put out his hand to stop me. He made a hand signal for me to wind down my window, and as I complied he lowered his head to my level and uttered these words.

“Choose a lane and stick to it, sonny.”

I trust he was referring simply to my driving and not offering a metaphor for life, but in an ever changing IT landscape does it have a ring of truth?

I’ve recently been considering software/hardware stacks for a new project. In many ways the project is green field – all the options are open. But, there’s never a green field because developers, infrastructure managers, project managers and more all come with a wealth of experience. I know that if you can learn to code in one language you will be able to pick up another one, but the more aspects of a project you change, the more everyone is going to have to learn before even starting the project.

Software development has fashions and trends, just like every aspect of life, and everyone wants to jump on the shiny new stack of the moment. There are so many options out there that it’s difficult which few to use as an example, so I won’t. But I have been investigating, both reading up on what the benefits of each stack are, and how straightforward it will be to install, configure and develop against.

My conclusion? Look to the future, but don’t forget they legacy, and don’t discount the experience that your team has already gained. Do you have someone with SQL Server experience, but less understanding of the nuts and bolts of MySQL/MariaDB/PostgreSQL – then use SQL Server, providing your infrastructure allows. If you’re using the Windows environment, then IIS is more likely to be a good fit than Apache, but both do the job well – don’t get hung up on it.

Server side and client side environments can be more flexible. You can run PHP, Node.js on Windows or Linux. Javascript of course runs client side and so is independent of your infrastructure choices. Again, if you’ve got a wealth of PHP talent, feel free to use it if it can do the job. But do consider the benefits of using a more modern language, and the cost in time and training against the improvements to development time, code usability, future proofing that moving on might bring.

For most development projects the crucial factor is doing the business analysis well before writing a line of code. The more time spent understanding the systems to be built, the faster it will be built, and the more likely it is to work first time. So, leverage existing experience and don’t get caught up in platform wars. Choose your lane and stick to it until a sign tells you otherwise. But work hard at understanding the system before you touch your code, or choose your environment, and then you’ll be halfway to building that system the best way you can.