CTO Handbook: Making sense of your Stack

A 4 step checklist for your business when picking a language or framework.

I’ve recently had an opportunity to design and choose the architecture of a couple of development teams. With that opportunity came a multitude of considerations. In each of these instances I felt it was appropriate to take an iterative and pragmatic approach; with some guiding principles in mind.

Here are my findings and some concepts you should consider.

1. Strong Ecosystem.

Loads of Stackoverflow answers. Great documentation. Established best practices. Engaged community.

Look for a language that has a good deal of questions with great answers. Take a step back and put yourself in the position of your most junior developer; are there Stackoverflow answers that address things like environment setup, answers on tackling problems similar to your application, and a great examples of pristine code(think the Awesome family of lists, and in particular almost any of Hugo Giraudel’s SASS projects for Sass Teams).

What this concept boils down to is a thriving community around the tooling and framework of your choosing. This isn’t a hard and fast rule, if you have a more experienced team it may be possible to go it alone, but I’ve found that teams with varying skill levels benefit more from a large community driven framework/language.

2. Highly Productive.

Code should be expressive as possible while allowing your team to produce features and iterate quickly.

The framework should allow for novices and fluent developers alike to express solutions easily. If you’ve chosen a framework that lends itself to sacrifice any of the aforementioned metrics; expressiveness, productivity and interchangeability, you should reevaluate your decision.

Code in your given framework should strive to best reflect the relations of your problem to your solution. The teams time in development should be as pain-free as possible, all while not driving you towards corners and development stagnation. This is a tough one as it is as much of a coding style and design consideration as it is an autopsy on the framework or language itself, but these are important considerations to make. This may take experimentation on your end ahead of time but it will pay dividends.

3. Extensible Abstractions.

If you develop a strong vocabulary for addressing and articulating problems, it makes for a better development experience now and in the future.

Does your framework make use of your core software development principles? For example, I’m driving my teams towards more functional thinking and ML based languages, so for me a language and a framework that has these features at it’s forefront are paramount. Concepts like mapping, folding and filtering are tools that will get us mileage in moving to more ML based languages. All the languages and toolings in our current stack have these concepts and features readily available.

Consider your vision of the future and how you’d like to speak about tech with your team. Does your framework or language leverage that vocabulary and make it easier to communicate about the problems you face? If not reconsider your choice.

4. Leads you to FRP (or your paradigm of choice).

Do all paths move towards your goals and align with your vision.

This is more my bias towards FP but I truly believe Functional Reactive Programming creates a powerful mental model for tackling most front end challenges. Viewing application state as a function of events over time transformed the way I thought about front end development. I believe we will continue to see Client Side frameworks like Elm that leverage this way of thinking and reasoning about UI development. All of that said; pick a framework and a toolset that drives your team towards thinking about your application in a way that aligns with your views on development and the technological goals of your business.

I hope you found this helpful and I’m unyieldingly curious on how people choose what language or platform to develop in. Comment on what your team is currently developing in and where you see your team headed in regards to language or paradigm.

Warren — CTO of Newscart.co