5 ms·
There's no single approach that works for everybody. What works best for you is dependent on several factors: - Whether you're primarily developing or maintain
by taylodl 2y ago
There's no single approach that works for everybody. What works best for you is dependent on several factors:
- Whether you're primarily developing or maintaining
- Size and organization of the codebase
- Size of the team working with the codebase
- Your production deployment strategy
- Probably others
Here's the thing: I know teams using trunk-based development and teams using feature branch development, and they all work in the same organization! Like most things in software development, the best strategy for you is dependent upon your needs and you should eschew the idea that there's only one right way to do everything.
- SideburnsOfDoom 2y agoYou cannot assume that in business, because a team is using a particular method, that this method is optimal, i.e. that it "works best for them". More often, it's just what they ended up with, and changing methods is hard. It may even be actively resisted. Teams need to be encouraged to "inspect and adapt".
- taylodl 2y ago> Teams need to be encouraged to "inspect and adapt". Agree 100% and that's on excellent callout.
- pjc50 2y agoSure, but there's also often a difference of opinion within the team and switching costs may be real and large. I'm not a fan of gerrit, which my current workplace uses, but I'm also resisting a move to github because doing so would involve rewriting a lot of CI scripts.
- SideburnsOfDoom 2y agoIndeed, the local optimum is in avoiding any drastic changes, which should not be made often or lightly. Switching costs and inexperience will drag you "through the valley" when making them with existing projects. I read "best" as global optimum but I know that's not the whole story. And working with like-minded colleagues on ideas such as this, is a very nice thing to have. It is something to seek out when looking for a new role.