Code reviews
A dear topic that I've struggled with in a lot of development discussions with various development teams is trunk based vs feature branch based development. And there is no simple answer what to use but pretty good evidence (eg: statistics from Accelerate - Building and Scaling High Performance Technology Organizations by Nicole Forsgren, Jez Humble, and Gene Kim) that trunk based development is indeed a way to build better software faster.
This is confirmed by my limited empirical tests with various teams for short term development projects. For long term product development the picture changes because the benefit of feature branches and working with code reviews in pull requests was never really intended for the software is was made to ensure people could learn and improve optimally. In the long run investments in people will lead to improved quality and less bugs as a side effect, but the short term cost is pretty substantial since it delays time to market and user feedback which are also significantly important for quality.
I think the main benefits from code reviewing is that it creates a platform for discussions which facilitates learning between engineers, long term this expands the knowledge and skills in the team. In a software product with the intention to be around for a while this investment has a very high value, this knowledge can later be used to improve the fundamental design of the product which has a much higher value than getting a specific feature slightly faster or with fewer bugs.
Can the best of both worlds be had? Yes, it would be reasonable to start out with trunk based development to quickly get the product out and gather critical user feedback, and iterate as fast as possible. Then later switch to feature branches and code reviews and reap the benefits of people learning. However this seems to be a difficult cultural move to do, the basic way of working is set pretty early and is difficult to change later. Improving efficiency in a later stage seems to be easier, having a team start with feature branches as the norm and as greater knowledge and confidence develops the individual engineers can "shortcut" the process with trunk based development when appropriate (decision taken at personal discretion). Although not perfectly optimal from a product development perspective it gets the best way of working eventually.
Last but not least, investing in learning is the right thing to do, as a leader this a moral responsibility.
This is confirmed by my limited empirical tests with various teams for short term development projects. For long term product development the picture changes because the benefit of feature branches and working with code reviews in pull requests was never really intended for the software is was made to ensure people could learn and improve optimally. In the long run investments in people will lead to improved quality and less bugs as a side effect, but the short term cost is pretty substantial since it delays time to market and user feedback which are also significantly important for quality.
I think the main benefits from code reviewing is that it creates a platform for discussions which facilitates learning between engineers, long term this expands the knowledge and skills in the team. In a software product with the intention to be around for a while this investment has a very high value, this knowledge can later be used to improve the fundamental design of the product which has a much higher value than getting a specific feature slightly faster or with fewer bugs.
Can the best of both worlds be had? Yes, it would be reasonable to start out with trunk based development to quickly get the product out and gather critical user feedback, and iterate as fast as possible. Then later switch to feature branches and code reviews and reap the benefits of people learning. However this seems to be a difficult cultural move to do, the basic way of working is set pretty early and is difficult to change later. Improving efficiency in a later stage seems to be easier, having a team start with feature branches as the norm and as greater knowledge and confidence develops the individual engineers can "shortcut" the process with trunk based development when appropriate (decision taken at personal discretion). Although not perfectly optimal from a product development perspective it gets the best way of working eventually.
Last but not least, investing in learning is the right thing to do, as a leader this a moral responsibility.
Comments
Post a Comment