2 min read
Over optimization is a technical debt in startups

When scaling our SaaS platform, we often need to rewrite services because of the market diversification we’re operating in. When rewriting anything, engineers (mostly in startups because they are highly passionate and energetic) often choose the most sophisticated and overwhelming architecture. One engineer proposed, “Why not add gRPC between our 3 services? Sure, REST works fine and we’re doing 50 req/sec.” Everyone started blushing and agreed to implement this because Google uses it!!

But after 3-4 months, things started to turn. We had to manage 3 services, gRPC connection issues, zero debugging tools. In the worst case, the engineer who implemented this left the company (this is frequent in a startup, don’t laugh).

We rewrote the service for better performance, reliability, and to prevent single points of failure. Instead, we got 3 services that failed in creative new ways. So we rewrote it again. One service, REST. It just works.

Not every service gets thousands of req/sec. Sometimes over-passionateness drives us to these kinds of decisions. If things are working, let them work, don’t touch. Mature code will not stop working.

So here is a simple observation of mine: Messy code may slow things down, but overly optimized code stops totally.