(no title)
dxdm | 7 days ago
Code should live in main/master and be in a production environment as soon as possible, but it does not have to run for all, most or even any customers/clients from the start. You can gate it behind feature switches, preprocessor directives, global constants, whatever. As long as it has an active purpose and is being developed further, it is not dead. Ideally, it will have tests.
The result of merging back to main often is that other changes will be made in awareness of your new code, and all merging will happen organically and in small increments. You also get to develop complex features bit by bit, in a way that can be verified in a real environment in a controlled way. And everything can be deployed anytime, which should happen often.
Being able to verify incrementally and get quick feedback lowers the risk of otherwise releasing a hitherto completely untested large feature into the wild in one go.
This does not absolve you from making sure that your changes actually work as intended. That will be easier if you portion the work into smaller chunks that are easier to understand than a whole, complex, all-or-nothing feature.
Of course you will still have to make sure that your small chunks fit together and make up a good "whole". However, the idea is that you're doing this exact work anyway when developing a larger feature on the side, but you might as well cut it up to deliver in much smaller increments.
This approach has its own costs and drawbacks, but in my experience it often produces a substantial net-reduction in friction and accumulated complexity and risk, and it keeps things moving, which is a benefit on its own. This is from my perspective in backend development, and it will not apply universally, but widely. Essentially, whenever you can get away with it, you should strive to deliver like this.
No comments yet.