[aethr]

Different levels of code quality are important for different teams / projects. Teams that are still discovering the domain and defining patterns should aim for a lower quality so they can iterate more easily. In this mode, knowing that code was written quickly and is fine to throw away / reshape is critical. Aiming for Very Good is likely to be a waste of time here.

In other projects, the domain is clearer, or the system already has well defined patterns that should be followed. In this mode fast iteration is also possible, but it's because the code is clean and follows strong patterns making it easy to understand. Good Enough code here is quite likely to slow the team down as they grapple with needless bugs and code that's hard to decompose / refactor.

The most important aspect of quality is that the team defines the level of quality that's needed for the project or the work being undertaken, and they deliver to that. Have the conversation up front about what level of quality to aim for and why. Then the team is on the same page, and everyone can move forward with the same expectations.

[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.