Why I think many teams and individuals follow an seemingly logic yet counterproductive approach to Software Delivery when building new product. Let's have a look at an alternative approach.
This was a great read, thanks Sergio! One of the counterarguments against working on the details of deployment and operation first that I often heard is that "we're not building anything yet, just experimenting to validate an idea". But to me, that's not a strong argument, because if you don't get external feedback, you're not validating your idea, you're just tinkering with it in a dark corner. So I wholeheartedly agree with you: figure out the bare minimum to get your non-existent product to production first, then start building (and iterating the CI/CD and infra together with it).
Another comment: Your article is aiming at greenfield projects, which, depending on where you work, can be extremely rare. Most companies I have experience with have one or a few well-established products, and they iterate or pivot from those, using their pre-existing codebase and environment. My point is that the philosophy of pushing your work live early and frequently still applies: Deploy frequently to production, and use feature flags to control the release of new functionality that's being developed. You'll get much more useful feedback if your Product team and earliest Alpha testers are using the live product with a feature flip, compared to any sandboxed test environment -- and you'll save yourself a world of pain not having to think about integration problems right before launch.
As you say, the article focuses on the greenfield use case, but the same principles apply equally, if not even more, to the more common brownfield initiatives.
This was a great read, thanks Sergio! One of the counterarguments against working on the details of deployment and operation first that I often heard is that "we're not building anything yet, just experimenting to validate an idea". But to me, that's not a strong argument, because if you don't get external feedback, you're not validating your idea, you're just tinkering with it in a dark corner. So I wholeheartedly agree with you: figure out the bare minimum to get your non-existent product to production first, then start building (and iterating the CI/CD and infra together with it).
Another comment: Your article is aiming at greenfield projects, which, depending on where you work, can be extremely rare. Most companies I have experience with have one or a few well-established products, and they iterate or pivot from those, using their pre-existing codebase and environment. My point is that the philosophy of pushing your work live early and frequently still applies: Deploy frequently to production, and use feature flags to control the release of new functionality that's being developed. You'll get much more useful feedback if your Product team and earliest Alpha testers are using the live product with a feature flip, compared to any sandboxed test environment -- and you'll save yourself a world of pain not having to think about integration problems right before launch.
You're absoltely right Péter!
As you say, the article focuses on the greenfield use case, but the same principles apply equally, if not even more, to the more common brownfield initiatives.
Thanks for bringing this up!