My previous company recently finished the majority of another quinquennial re-platform of our web applications. I joined at the tail end of the first one and I naively expected this one to go as smoothly as I had imagined.
Oh boy, was I in for a ride.
If you’re familiar with the wheel of time that plays itself over and over again in the tech industry, you know you can usually expect a major re-platform every 5 years. Most of this is attributed to how fast technologies are forming and changing. It’s become so easy to pick up a language, learn online, and build things without copious academic backgrounds and on-the-job experience, that we’re blessed with new tools on a daily basis. Many of these tools are so impactful and revolutionary, failing to adopt these changes means becoming outdated in the best case and unviable as a business in the worst case.
For our organization, the key goals were to rethink business perspectives and to rebuild the tech stack to align with the North-star vision of a highly performant, user friendly, and modern omni-channel experience. There were too many times when we had to turn down innovative ideas because our app was too fragile, we had too much maintenance work, or it required too much refactoring. Our technology was holding back our innovation and it was time to upgrade our technology in order for the business to thrive.
So onward we marched, all for and one for all.
Through countless proposals and the persistence of our brilliant engineers, we doubled down on re-platforming efforts and reconsidered every tool and process within the organization. Among the dozens of new tools we decided to adopt, the two most notable were NX and Nextjs. More specifically, we decided to leave behind all our siloed apps and unify them into a truly single page application in one repo. To my readers coming from startup backgrounds, this may not be so much of a shock, but to those coming from traditional enterprise backgrounds, this may trigger some PTSD.
Why on Earth would we blur the lines between all the spaghetti code even more than it already is? The major decision drivers behind adopting a monorepo SPA were (among others):
- Easily implemented, executed, and enforced end to end testing
- Performance gains from client-side rendering between different pages
- Consistent code and CI standards across entire organization
- Easier to write DRY and cleaner code
- Easier to collaborate across different teams and initiatives
- Work done on platform tools benefited everyone immediately
When I was first transferred into this effort, I was in tech bliss. The teams were truly agile, I built multiple features a day all with robust test suites, everybody was on the same page, merging your code was quick and painless, every team was aligned on the same priorities, platform tools were simple to use, documentation was up to snuff, and tweaking parts of the app not immediately within the scope of your team was ridiculously easy.
But all that glisters is not gold.
The ideas were great, but we struggled to scale. Our model worked well going from 10 engineers to 40, but not so well scaling to 200 contributors (and counting):
- Enforcing the same coding standard across every page seemed too restrictive and limited developer productivity
- When a platform tool broke, only a very small subset of engineers had the technical knack to provide support
- We started creating “god” modules, which in the good intention of trying to reuse code across different pages, we ended up with a single component that called 20 hooks, 20 props, and 10 different use cases
- Our testing tools could have scaled, but we didn’t have enough resources to actually wire them up properly
- Something breaking the CI on one page would block merges for every other team
We started stumbling, then tripping, then resorted to rolling down the hill. But hey, at least we were rolling fast.
Reading that list, you might be thinking “Hey, we have those issues too!”. Well that’s because all of those will always be issues in some shape, way, or form. These issues aren’t specific to this company or to this re-platform. That’s what makes our job what it is — we build solutions, scale up, identify pain points, build better solutions, and repeat. What was really keeping people up at night was that we were so preoccupied with the technology that we failed to change our way of working and thinking to scale. We became obsessed with building things perfectly, taking on 0 tech debt, blocking PR merges due to minor differences in coding standards, and ultimately becoming too siloed in our respective pages. Now that we started on the same playing field, everybody was an expert and had their own vision of perfection. With the platform team tirelessly breaking their back trying to hold up the entire… well… platform, page specific teams strayed further from collaboration causing the same political tension, hurt feelings, and burnout that always seem to come as a buy one get three free deal with re-platforms. We were now a single page application but not yet a single team. What made this exponentially more difficult was we are all doing this with good intentions.
The technology scaled well, but we, as humans, could not.
So what’s the moral of this story then? I guess nothing I said would have come across as new to most of you, especially considering the things I’ve read on Blind. This is more of a reflection and also a reminder for myself to think of technology from the human aspect more than the technology itself. So take what you’ve read with a bucket of salt and think about how you can steer your next re-platform in the right direction. There’s nothing inherently wrong with monorepo and SPA. What was more evident was our lack in preparation for how to re-platform our people and culture.
Could our pains have been avoided if we all went into this with a different mindset? What if platform support was every team’s responsibility? What if every engineer rotated working on different pages? What if we engrained the importance and value of testing infrastructure and tools into our recognition rubrics? How can you re-platform not just the tech but also the culture?
So many re-platforms focus on “running away” from past mistakes when we should instead be embracing it and using it as the foundation for what comes next, both tech and culture. Maybe after a few more re-platforms in my career I’ll become jaded, but I don’t want to be. I want re-platforms to be less painful and more fun, evolutionary, and most importantly, human.
And so my journey continues, through thick and thin, navigating my way around the most complicated platform of all, us.
