🚀 How far do you take releases?

Thus far, we have defined a release as something that is useful and high-quality. Typically, we think of a release as something formal - v1.3.8 that is packaged, built, and announced. But we can push this further. What about pull requests? Is every pull request that is merged at the same standard? Or do we merge them and hope that something later in the process will magically transform the work into something better? "Later never comes" - especially in complex systems.

Open-source projects have figured this out. The standard for getting a PR merged is incredibly high in most projects. Why? Because there is no business pressure to merge it, but rather the fear of having to maintain something that is substandard. The maintainers are looking out for their own selfish interests, but these interests happen to align with the realities of this kind of work. Fixing something after the fact is so much harder than doing it right in the first place. As a result, most OSS projects maintain fairly high quality at any point in their development. This is one reason Arch Linux works so well.

While there is a place for brainstorming, prototyping, experimenting, etc., this will not get you very far developing a real product. The earlier you push the "release mentality" into the development process, the faster you'll move. Maybe not in the initial steps, but for sure once you are a third of the way through the development cycle. Do you want to save time on the first third, or the last two thirds of the development cycle? Hint, the Law of Compounding is at work here ...