The bane of tech stack decisions

Last Update: 11.02.2020. By Jens in Newsletter

I’ve written about this before but as I run into this topic again last week, I thought it’s a great reminder for all of us. Don’t have time to read? There’s a TLDR at the end of the email.

I wanted to add some features to my ambient sound generator app Zenmix.io. So, the first decision I had to make was if I wanted to stay with the current tech stack or move to a new one. And which one. So, let’s start there.

The original app was using JQuery and a JQuery plugin for the audio part. Both versions were pretty outdated. The plugin’s last release was somewhere in 2014. Sure, it does its thing, so why change it?

The answer is JQuery. Or more concrete the experiences I made in many projects with it and that is was always a hassle to maintain these. Besides, there arose better ways for building apps like vue. I uses vue in POV project last year and was pretty satisfied with it. However, I am not keen on those JS build systems, so I also thought about using plain JS for the front end. But then I had to write everything myself. hmm. Finally, I settled for vue with the big assumption I will be faster. We’ll see if it was a good assumption farther down.

The next thing was I needed a backend now for the new features. My first thought was Spring Boot and probably I’d coded the damn backend including auth in a few hours. But on the other side it meant, I had to host it somewhere else than on Netlify. Which works as I have done this in other projects but it is a moving part more that can break and also probably an expense more. I’d didn’t like that at the point of making the decision.

Another point was, that Netlify offered its Identity service for user and auth stuff with a JS lib and on their backend. Yay. And of course, they got functions, so I could put everything on Netlify and have a single hosting point. As they also solved the data storage probs in the form of a FaunaDB integration, the decision was made. I went with the Netlify stack for auth and the full backend instead of Spring Boot.

The question now is: Was it a good decision?

And that is the hard part because you never know which alternative would have been better. You don’t know in advance and you can’t do it in both stacks without influence. We would have to start a parallel world and see which ends up happier :-)

Anyway, now let’s get back to the reason for my mail. What I didn’t mention so far is, that I had a time constraint. Wanted to have thing done in 2 days. lol

But as it is with new tech stacks and time constraints, they do not work well together. Which is normal because you do not know which issues arise with the new tech, nor how you can deal with it. And that was the main reason why it went way over my 2 days estimations. Actually I needed 6 days to complete it. Not everything of the delay was due tech issues. I underestimated UI for auth and user mgmt flows too. Doh!

It’s fascinating how easy it is to fall into those probs even when you have been coding for a long time. Especially easy, when it’s your own project.

What could I have done better in the beginning?

In my case clearly adjusting my plan and my expectations. The tight timeframe was the culprit for any stress. Yeah, the stack had had its frustrations too but the main prob were my expectations. So, either removing the deadline or keep it and use Spring.

However, more important is to keep those things in mind when planning. Especially, when working on large projects and with a team. Not every team member has equal knowledge or skill. We are always learning but it seldom is part of any project planning. More often than not those arbitrary 20% buffers a PM adds are used :-)

TLDR;

  1. When the project is time-critical, do NOT add new techs, languages, framework, etc
  2. When you add new tech, make sure it is reflected in your project plan as your estimation will ALWAYS be off by a larger magnitude.