Hacker Newsnew | past | comments | ask | show | jobs | submitlogin

Superior strategies like this are like hidden lore. Why is that? I'm certain there are dozens or hundreds of these hard won lessons.

I had to rediscover the "INSERT only, no UPDATEs" trick on my own. Changed from separate truth and historical tables to a single table which is groomed over time. Major simplification. A few extra benefits: like scaling, testing and auditing.

And my peers absolutely lost their minds. A senior VP rolled back my architecture the moment he could. (We were acquihired, so this meant major upheaval of systems which had be in use for over 3 years.) My solution was just too weird looking, too unorthodox.

So while there's lots of things we can do to mitigate databasization and buy ourselves some head room, we don't.

Square peg, round hole?

My radical (unoriginal) thought is the problem is the people, not the tools.



Sorry, this is example of my muddled thinking. Here's another shot:

Real world is messy, evolving. Schemas and programming languages encourage rigidity, but can be more flexible. So while we can design and use adaptable systems, we don't.

An additional theory I have is that the people drawn to our type of work have rigid views and strive to make the world more ordered, through their systems, rather than accommodate the chaos. Aspirationally. Not in truth. Because I regard most of our efforts to be rather chaotic.


"INSERT only, no UPDATEs" - sounds like event sourcing?


Or an append only log. Either way, not things unheard of in software engineering.


Obvious in hind sight.

Fowler's Event Sourcing [2005] https://martinfowler.com/eaaDev/EventSourcing.html

Published after I stumbled onto my solution.




Consider applying for YC's Fall 2026 batch! Applications are open till July 27.

Guidelines | FAQ | Lists | API | Security | Legal | Apply to YC | Contact

Search: