Lessons from 25 Years of Software Architecture

I’ve been designing systems for 25 years — across a tutoring centre, a law firm in DC, a healthcare platform in Mumbai, and now a hardware company. The specifics rotate. The lessons don’t.

1. The best architecture is the one you can explain

If your team can’t sketch the system on a whiteboard in five minutes, it will drift. Architectures survive because people carry them, not because they live in a document. Optimise for explainability over cleverness.

2. Constraints are a gift

Early in my career I resented every “you can’t use that” handed down from compliance, legal, procurement. Now I realise constraints are the thing that force good design. An unconstrained project always turns into a science fair.

3. Choose boring technology, on purpose

Postgres, SQL Server, Linux, a well-known web framework. You get to spend your innovation budget once — spend it on the thing that actually differentiates the product, not on the database.

4. Decisions, not frameworks

I’ve seen teams spend months on a migration from Framework A to Framework B only to land in the same mess. The framework was rarely the problem. Decisions were: ownership boundaries, data contracts, deployment topology. Fix those, and the framework barely matters.

5. Architecture is leadership

The most senior thing a CTO does is not pick a database. It’s create the conditions where the right design emerges. Hire well, remove blockers, say no clearly, and celebrate when someone on the team has a better idea than yours.

The juniors I worked with 20 years ago run their own companies now. That’s the only architecture metric I actually care about.