[hinkley]

The problem for the last 4 decades has been getting people to admit that we were 'building one to throw away'. In the last 2 we've tried a couple of different tricks to get things done anyway, with varying degrees of success. But that's all external-facing problems

The internal facing problem is getting a team to agree to differing quality gates for different parts of the system - the absolutely knowable and the arguably unknowable parts should not be written with the same mindset if you want to maintain velocity. If you get lucky with the org chart you can fake some of that quality diversity via code ownership, but that's a rough approximation at best. People seem to prefer picking something static and not thinking about it too much, rather than having to reason about every feature. I'm curious to see what we try next to deal with this.