Standardizing a tech stack for a startup team is a critical and complex decision.
Engineers come with unique backgrounds and preferences on how to build a product.
You can’t try them all and see which one works best.
Or can you?
Ian Lotinksy, VP of Product Engineering and Design at Weld North Education, believes that experimentation and research should be expected from engineers. When his team was faced with a forced migration, they decided to test various frameworks until they found something that met their needs.
In this article, Ian explains the process his team used to choose a framework, and he highlights the importance of learning on the job.
The conversation below has been edited for length and content.
What tech stack does your team use?
We use Ruby on Rails on the backend and Vue.js on the frontend.
The backend was selected by the consulting firm that built the first version of our product before I joined. But it’s the framework I’ve been using since 2007, and quite frankly, I probably wouldn’t have considered this company if it wasn’t using Rails.
The reason why a lot of us choose Ruby on Rails is because it has some basic tenants or values in its architecture that are pretty unique and results in extreme productivity.
Most web applications are trying to generally solve the same technical problem: creating data, reading data, updating data, and destroying data through web forms or something similar.
Since all these applications are trying to do the same sort of thing, it’s possible to have a highly opinionated framework that puts forth pretty much one official way of doing things (with the option of breaking outside that if you really want to).
A lot of other frameworks try to abstract or generalize things from the beginning so that people can plug in and play whatever components they want into the system. In a way that dilutes its ability to be efficient.
It’s refreshing to have a framework that is opinionated about how to get something done. Because then there’s convention around it, there’s tooling around it, and you can just use it. You don’t have to worry about the basics.
We use Vue.js for some similar reasons. Their tenant values are actually inspired by the Rails project. They have similar concepts around very clear patterns for how to get things done. Plus, there is a belief in convention over configuration. They form a convention that the engineers use so they don’t have to spend too much time configuring things.
Vue.js is probably the leading competitor against React. And React has inspired some of Vue.js’ opinions.
But we’ve found that opinions about convention over configuration have been more refreshing and simpler. It’s really been more of a joy for the engineers to work in.
Did you explore any other options?
In our history, we were using Angular 1.
When they were upgrading to Angular 2, there were vast differences that required us to rewrite our applications.
That decision by Angular made us question whether we wanted to stick with that framework. It was such a breaking change.
We decided to experiment with reimplementing our search using Angular 2, React, Knockout.js, and several other frameworks that existed at the time.
Having the team do that on Fridays for about six weeks, we quickly learned what we liked and didn’t like about the various JavaScript frameworks that were out there.
We picked Knockout.js because it was something that could gradually be brought into the project. Then later when the Vue.js project came out, it became even clearer that this was the thing that we were hoping would have been out there when we did this exercise of trying out all the different frameworks.
It just so happens that it’s a pretty simple migration path from Knockout to Vue.js. (I think even some of the core team members of Knockout.js were on the Vue.js team.)
It included the use of the same patterns and it was easy to write a bridge between the two frameworks so they could actually talk to each other. Then we started migrating stuff over.
Going through the exercise of trying out each framework to solve a problem helped us understand what we valued. So when the right framework came along, we were able to quickly say “Oh, this is it.”
We understood what we were looking for.
Should more companies allow their engineers to experiment with frameworks like that?
There’s a fine line between being so restricted about your employee’s time that you don’t let them experiment with anything and giving them complete flexibility.
Employees need the freedom to experiment with stuff on the product that they’re shipping. If you don’t give at least two to four hours a week, especially if they need to solve a program, it can really hinder someone’s growth and keep your team from finding and using new solutions.
I tell my team that I expect them to do research throughout the day on the things they’re trying to solve.
That’s not so hard to imagine today. But when I was working at my first job out of college, I had a manager tell me that I should look up things on my own time – whether on nights or weekends.
That didn’t make any sense to me.
I’m stuck on a particular problem right now and I’ve got the book right here. Now is the time for me to spend 20 minutes understanding possible solutions and making the right decision. There’s a lot of value in thinking before leaping.
But there’s another problem that exists, particularly among small companies.
They give too much freedom to software engineers. They let them use whatever tool they want to solve a job.
It sounds like it wouldn’t be a problem. But engineers can be tinkerers. They got drawn to technology because they enjoyed it and it was fun and interesting.
But you trade that for the satisfaction of adding real value to the world. It’s possible to pick too many technologies for your business.
I could have said, “Bring in whatever frameworks you want into our live production environment anytime if you think it’s helpful.”
I’ve seen those types of projects. They have moldable JavaScript frameworks installed, or they’re using many different backend frameworks or programming paradigms.
There are economies of scale in picking just a few sets of technologies for your team to train up on, use for testing, and use for development.
Once you branch out into too many frameworks, you start to slow yourself down with overhead tasks.
How do you balance experimentation and branching out too far?
The search reimplementation experiment we did was with throwaway projects.
Over a six-week period, a pair would implement a set group of features for the search experience. They would implement the first two features, and then the next week everyone would switch frameworks and implement the next two. So on and so forth.
We had one repository for each of the frameworks we were experimenting with and people would rotate through the repositories. They’d learn how to use the new framework, build with it, and see how easy it was to pick up from the work others had completed.
At the end of the project, we ended up just tossing everything. None of it ended up in production.
Yet the experiment helped us pick the framework that we ended up migrating over to.