Engineering Resistance Is Good

Recently, we had an engineer request to add web components into one of our repositories. Web components have been gaining a lot of momentum recently; their flexibility and speed is a deviation from the way we do things with our traditional frontend libraries like React, Vue, Angular, etc. Libraries like Lit have made it possible to wield the power of web components in a scalable way. They look great!

However, it's no question that integrating web components into our existing repositories would be a mistake. All of our existing frontend structure, including our design system component library, is written in React. Which means all of our engineers are fluent in React, and we've spent years developing patterns and best practices so that we can build fast. On the surface, adding web components as an experiment doesn't seem bad, however, bad code is infectious. Engineers copy and paste things they don't understand, dependencies require X and not Y, and things just grow over time.

So what starts as a test of a new technology soon becomes a new thing we support. It's a new thing we have to educate our engineers about, a new piece of infrastructure we have to support and upgrade, a new requirement for onboarding engineers to learn, a new checkbox for prospective engineers to have experience in. The code base would blend between these two technologies, and within a few years as engineers turn over, we won't know reasonings between why this and why that.

Mentioning that we should consider web components is not a mistake in of in and of itself. The dialogue is good, and I'm happy onlooking engineers can view the discussion.

What I'm really happy about is that there was appropriate friction in place to say no to something. Friction to prevent technical debt, to prevent a pollution of a codebase unnecessarily. So often, we take pride in the speed at which we build things that we forget it's necessary to pump the brakes sometimes. Chasing the next great technology is usually a bad idea for an existing codebase. Sustainable product growth and a well-documented engineering process is better than whatever benefits that new tech may introduce.

So, contrary to what I've written in the past, here's a toast to moving slow and saying "no". Hell yeah.