It looked brilliant on the whiteboard

We paid for it for years.

Early in my career, I built a data collection system for the pharmaceutical industry.

The requirements kept changing - new fields, new structures, new types of data to collect.

So I designed what felt like an elegant answer: a dynamic field structure, stored as documents inside a SQL database.

Infinitely flexible. No schema changes needed.

The design practically applauded itself.

On paper, it was smart.

Then the system met time.

The first real test came when we had to extend it with a new structure.

Suddenly, extracting data meant parsing documents the database couldn’t see into. Queries became harder. Finding errors became harder. And the flexibility that looked so elegant on the whiteboard became complexity every time we had to change or understand the system.

So we did what teams do when the architecture fights back:

We built more architecture.

Custom tools to manage the structure. Mirrored datasets just to summarise the data at usable speed.

At some point, we weren’t maintaining the system anymore.

We were maintaining a system that maintained the system.

Here’s the irony: the instinct was right. A few years later, flexible document databases became an entire product category.

The idea was good. The implementation was mine.

That distinction has followed me through every project since.

“Smart on paper” is one of the most dangerous phrases in engineering.

The whiteboard never votes against you.

Day 500 does - when someone has to find a bug in field 47 of a document no schema describes.

Elegance on design day and maintainability in year three are two different currencies.

I’ve learned to price my decisions in the second one.