This is straight up LEAN type thinking. A core tenet of LEAN is the understanding that quality is an intrinsic part of whatever process is in play. A secondary one is short feedback loops coupled with localized authority / capability to identify and resolve problems quickly. (and I've taken liberties with this to frame it in somewhat relevant terms for software)<p>...those get reported upstream and ideally are used at the front end to improve though efforts like design for manufacturing. Translated to software might result in "spec for coding", meaning easily identified tests happen up front, library / common code use cases factored into the spec to limit new feature create to those features actually adding value, not redundancy, etc... Less new code, more code generated code, and reuse of code.<p>Additionally and regardless of the up front changes, I see this as writing tests concurrently with writing the end use code. Spec, test, code, in LEAN terms, are tightly coupled and managed together. At first, doing this is an investment. People require training, process issues, communication issues, flow issues all will combine to lower the overall productivity. But, it tends to resolve and then resonate. Once that point of resonance hits, everyone gets it, quality will go way up as will productivity.<p>It will remain possible to go faster in the short term, and that risk / reward will always be tempting too. What is worth what?<p>That, to me, is the most interesting question.