New technology is always exciting for us engineers. A new programming paradigm, a new programming language, a different library, a different database. We are always looking for novelty and eager to learn, but users don’t care about what technology your company uses. As long as your product works, they’re happy. Did anything in your life change when YouTube started using Golang? Wait, you didn’t know, did you? Don’t worry, it doesn’t matter.

Many years ago I worked with a few senior engineers at Globo.com and we liked to pick the best technology for the job (in our opinion). Our technology stack was diverse; I worked on projects in C, C++, Python, Ruby, PHP, Lua, JavaScript, and ActionScript. With each programming language, we’d have a completely different set of tools, different ecosystems, and also a lot of risks (unknown unknowns). Hiring was extremely hard, getting an intern to be successful was nearly impossible (we gave up after three attempts). I still believe that most of our choices made sense for our reality of live video streaming, but that’s not the reality of most startups and not my current reality.

A couple of years ago, my CTO, Steve Pulec, shared the article Choose Boring Technology. I recommend everybody to read this article, it may change how you view technology choices and it served as inspiration for this article. You can find more information about it on http://boringtechnology.club.

Cool Tech at Startups

Back in 2013 one of my colleagues was angry because he suggested a new programming language for a project and someone told him (paraphrasing): “I don’t think startups should use this language.” I shared my colleague’s anger because I thought startups were the cool environment where developers should be playing with new technology all the time!

This story is interesting because at that time we picked gevent for a project because somebody was learning the library, though it was cool, and it made sense for the project because it was about async work in Python! You can always convince someone to use new technology, but you need to prove it’s a good idea for the long-term. I’ve seen leaders accept technical decisions to not hurt engineers’ feelings or bring down team morale; sometimes that’s necessary, but it must be a calculated risk.

I remember asking a colleague how he was debugging the system built on gevent, and he said: “I disable gevent when I’m debugging or running the tests.” That system evolved, got new features over time, new engineers worked on it, it eventually became a monster because nobody knew exactly what was going on, and not many people were committed to master the tool. That decision had a similar impact as a programming language choice: you need to be 100% committed to it. It’s easier to look back and say the gevent decision was a mistake, given our context at the time. We spent a couple of years moving the project slowly out of gevent and integrating it with the rest of our standard tools. I’m seeing something similar happen to us in regards to React.js (we recently lost the two engineers that were big proponents of React.js).

My opinion about new technology has changed over the years. I’ve been at a startup for almost six years now and I’ve seen the negative impact of new technology in some situations, such as when it’s overly complex, nobody has experience in it, it doesn’t play well with the rest of the development tools, or people aren’t fully committed to making it work.

Conclusion

Most startups are trying to survive and find a scalable and repeatable business model. Focus on your product development and use the technologies with the lowest risk of failure.

Should startups go after the shiny tech or should they stick to the time-tested boring technology that works? There has to be a balance, of course. I think research & development is necessary to build a healthy engineering group. I recommend everybody to experiment with new tech, try it on pet projects, change a couple of small projects, but never forget that this is still an ongoing experiment and you may need to revert your changes.

The best tech decisions tend to be the ones that won’t put you in a corner when they are proven wrong.

Ask yourself the following when deciding on new technology:

  • What experiments can I do to validate this?
  • Will this still work in a couple of years?
  • Can I get new hires productive quickly on this?
  • If I realize it was a bad decision, will I be able to switch to different technology in a timely manner?