What a CTO needs to consider, When choosing a technology stack

When I was a developer, I always wanted to use the latest language and framework. I would accept the foibles of the framework, just because it was new and cool. Spend hours setting it up, installing all the different components, writing a simple application and then deploying at the click of a button …. only to spend hours in the server backends, trying to understand why it did not work!  I’d then get a exciting new job using the framework, and be immediately lauded as the star developer, which in truth became more like first line support.

As CTO, you should always be super aware of trends, but very weary about jumping straight in. Can you afford to lose man days, whilst the team gets it head around new technology. They might be having fun, but you’re getting nothing done and that costs money.

When evaluating a framework as CTO, alongside the normal technical considerations you need to take into account;

• the number of developers available (if few then you will struggle to fill your team)
• cost of developers (either because it is too few or requires a high technical skill)
• the cost of the framework if it is not opensource particularly if it is discounted for start ups but quickly ramps up outside of the startup criteria
• time to set up (for developer’s machine and continuous integration)
• time and complexity for deployment (whilst improved much in the last couple of years, I have lost hours of my life getting to the bottom of incompatible components)
• fit for purpose (you should know the vision of the company so will the framework be suitable not only for now but in the future)
• suitable for growing teams (does it allow a new developer to get up to speed quickly due to its layout and encapsulation i.e. they do not need to understand the whole code base before starting work)
• active support (even with having access to the code with open source does not mean that you want your developers spending more time in that code base than yours)
• security (this will be dependent on your application but if you are using the frameworks security components that they are robust and their methodologies understood)

If you’re starting a new project, you should have a shortlist of suitable frameworks that can be used. Evaluate each based on both the technical and commercial reasons above. If you want to introduce a new framework, think about getting one developer or at most a small team, to evaluate and potentially create a simple prototype to confirm its suitability.

Finally, a counter point to raise …. don’t choose your favourite, just because you know it as that could also turn into an expensive mistake.  When choosing a technology stack – favourite, existing, pioneering – you must do nothing less than a thorough evaluation to find the most cost effective solution for your company, at that moment in time.  It’s one of the primary responsibilities for any successful CTO.

Choosing the technology stack is one of the many tasks requested of the CTO and if you’d like to know more, why not read our article with more information about CTOs.