Code is easy to refactor or rewrite. Changing code is computationally inexpensive. Not true with data. Data outliving code is a good problem to have, usually reserved for successful companies..

Code is easy to refactor or rewrite. Changing code is computationally inexpensive. Not true with data. Data outliving code is a good problem to have, usually reserved for successful companies..

I wrotes these principles down in 2015. At the time they felt "visionary". Looking back now I love these principles even more, but they seem obvious and ordinary now.

Engineering teams love full rewrites because they incorrectly think of old systems as specs. They assume that since the old system works, all functional aspects have been settled. Design risks have been eliminated! They can focus purely on adding more features to the new system, or making changes to the underlying architecture without worry. However, the belief that new code is better than old is patently absurd. Old code has been used. It has been tested. Lots of bugs have been found, and more importantly fixed.

A similar but inverse brainstorming exercise to the critical factors exercise is asking your team to play saboteur. If you wanted to guarantee that the project fails, what would you do? How can you achieve the worst possible outcome? Once this list is generated, you know what to look out for.

Anyone who has ever been responsible for supporting production systems learns some things along the way. For example...