Good point that you can get from this talk is that you do trunk based development ONLY when you trust all of your developers and have good automated testing. I would hate having to revert junior changes every day.
That's irrelevant if you do pair/mob programming because then no junior code will even reach a commit and even less a push. Also with pair/mob programming they won't be junior developers for long. There is no better way of learning the senior ways.
You can do TBD with PRs gated by code review. Just requires keeping the PRs short and merging them within 24 hours ish / 8 working hours from origination. That's still very doable ish, e.g. junior takes up to 3 hours to make the pr, start review it within the next three hours, and then reviewer and originator work together to get it mergeable in the remaining 2 hours.
Then work with that junior, so you don’t have to revert their changes and they can learn from you. And when you hire people, you are supposed to trust them. Having good automated testing should also be a fundamental rule.
The note on feature flags is a bit confusing and contradictory.... I mean - all developers, all the time should be running with %100 of the features turned on time but, what, write modules, but hide stuff from the user - with what - feature flags? I see some major security implications by putting incomplete code into production this way.
I found feature flags very helpful, but especially with bigger teams they breed like rabbits. It's important to ensure created flags are phased out quickly otherwise it becomes a big mess. So discouraging feature flags makes some sense, but it would IMHO be better to teach how to use them well. We used feature flags for example to implement experimental features to present them to users in meetings and only turned them on for production if they were satisfied. After a few days in production we removed the flags. This made it easy for admins on customer sites to disable just rolled out features if they caused issues or they could decide when the best time is for them to enable new features.
It’s incomplete code but it’s hidden from the user, so it’s not released into production. There are no security issues until it’s released. Feature flags help separate deploying from releasing. The benefits of continuous integration are immense and the little pain of using feature flags is worthwhile. Yes, developers test with all feature flags turned on, because the feature is there even though is being worked on.
Reasons for not working at Thoughtworks. - Pair programming is like living in an Indian family, with no sense of privacy. Rarely this leads to deep work. - Unable to understand, writing integration tests are more useful. Its like oh you want to write a sum function? First write a test. Some devs I have worked, will write tests and assume their code works, push it to remote only to be surprised when it fails with an actual API call. There will always be points of time where Merge Conflicts would come up, and the worst part is, its generally left upto the developer whose branch the merge failed, instead of a collaborative effort. I mean when you have to explain to a bunch of intelligent audience what a regression test is, and how to run tests, you know its outta hands.
I found remote pair programming quite satisfying. We didn't use the camera most of the time. We just used collaborative editing features of VSCode. Half of the time we worked individually on different parts of the feature (like boring boilerplate code) and half of the time together on the more finicky parts. We usually had the mics on, but we didn't talk much. We even used this setup when we were in the office sitting next to each other with headphones to not disturb colleagues more than necessary. The testing stuff sounds weird. In my experience with pair/mob programming most people raise fast to a niveau where such basic issues are a thing of the past. Of course only if senior devs are not afraid to share their knowledge.
I mean, if you are stuck on something or either you are learning something from the other person or like mentoring someone. That is a different usecase. But this continuous talking while coding, it's pretty annoying man. I mean atleast for me. If you can do it. It's fine. But like my way of thinking isn't also right for everyone. I am probably one of those menace who really doesn't know how to fit in. But I just can't work like that. Most of my roles have in IC genre. And I do need mentoring, I think of the ideas, write it down, discuss it with senior people or junior people depending on their expertise level. And then go along with the day.
Really nice overview… as someone who has never worked in an org that practices trunk-based development, I’m eager to join one, and one day hopefully lead a team where I get to fully explore these ideas. One thing I’ve noticed is that the sum seems to be greater than the parts, in that these ideas really bear fruit when practiced in concert with one another. It can just be so challenging to find people who are willing to try out practices that feel unfamiliar, like TDD and pair programming, even if you swear until you’re blue in the face that the best work of your career has been borne out of that type of workflow.
That's not my experience. The main problem with burnout is in my experience management that demands agile-like velocity but prevents agile methods at every step and usually encourages competitive behavior over cooperative behavior.
Typically people that employ TBD work in a better, faster and happier way, that's also because generally teams that employ TBD also practice TDD, Pair Programming etc. If you (or DORA) want to look at which individual practice might create discomfort, then I'd agree there are plenty that when used in isolation might have inconvenient side effects, even the fictional story presented in the talk goes through several hiccups, despite practicing TBD and CI.
Trunk-based development can cause burnout when applied in places that don’t have the right safeguards to make it a smooth experience. When those practices are adopted, TBD is the best way to work. It’s continuous integration. It makes your job easier, the usage of tools less complex, it makes indeed developers happier. The best results are achieved when adopting a test-driven approach and social programming practices (pairing/mobbing).
Incidentally it is the first DORA report which Forsgren themselves did not participate in. Forsgren themselves said that something's fucky with the reports methods which made them arrive to that conclusion.
I find there is much more friction when you find some a problematic piece of released code than if you spot/were pointed out to it in the PR review. If that caused distrust in the team, there are other problems within that team. There are projects where code reviews are pointless and bring no value, in others they are priceless and save tons of money and stress. The ecosystem is just much more complicated than "let's do TDD/TBD/Scrum/whatever overhyped acronym"
You misunderstand code review to always be a separate form of activity inside a team. When pairing and mobbing the people review what is written constantly. Post-integration reviews and general codebase observations are just a great addition to that form of constant review that is done in group settings.
A bit weird how she moves from 'Big PRs are impossible to review, don't do that' to 'review whole code base/areas'. Also post-factum reviews, even though valuable, can't prevent changes before they happen. Good luck undoing some schema or infrastructure changes and while automated tests can prevent bugs they can't verify if developer understood the feature well. Local testing might not be possible besides simple unit tests and those are already understood to have limited value. Pair programming on the other side is completely delusional IRL. It's super effective for 20min after which you become completely passive. It's also draining and impractical, even ignoring the remote work and timezone issues. Plus none of those practices is exclusive. If you pair-programmed something you can merge PR immediately together. If you can't or the peer wants to recheck it on his own screen/IDE, he can do it.
You're projecting your personal experience with pairing as an objective truth. There are tons of people who feel differently. Were your experiences with pairing done with the so called strict style pairing (i.e. rotate driver and navigator with a timer), or did you just sit down and one of you coded while the other observed?
Good point that you can get from this talk is that you do trunk based development ONLY when you trust all of your developers and have good automated testing. I would hate having to revert junior changes every day.
That's irrelevant if you do pair/mob programming because then no junior code will even reach a commit and even less a push. Also with pair/mob programming they won't be junior developers for long. There is no better way of learning the senior ways.
You can do TBD with PRs gated by code review. Just requires keeping the PRs short and merging them within 24 hours ish / 8 working hours from origination. That's still very doable ish, e.g. junior takes up to 3 hours to make the pr, start review it within the next three hours, and then reviewer and originator work together to get it mergeable in the remaining 2 hours.
Then work with that junior, so you don’t have to revert their changes and they can learn from you. And when you hire people, you are supposed to trust them. Having good automated testing should also be a fundamental rule.
so new so fresh =) oh wait, Simpsons already had it... a long time ago... and then git was introduced...
Excellent talk: Review the whole holistically - the area you are interested in --- this is much more efficient
The note on feature flags is a bit confusing and contradictory....
I mean - all developers, all the time should be running with %100 of the features turned on time but, what, write modules, but hide stuff from the user - with what - feature flags?
I see some major security implications by putting incomplete code into production this way.
I found feature flags very helpful, but especially with bigger teams they breed like rabbits. It's important to ensure created flags are phased out quickly otherwise it becomes a big mess. So discouraging feature flags makes some sense, but it would IMHO be better to teach how to use them well.
We used feature flags for example to implement experimental features to present them to users in meetings and only turned them on for production if they were satisfied. After a few days in production we removed the flags. This made it easy for admins on customer sites to disable just rolled out features if they caused issues or they could decide when the best time is for them to enable new features.
It’s incomplete code but it’s hidden from the user, so it’s not released into production. There are no security issues until it’s released. Feature flags help separate deploying from releasing. The benefits of continuous integration are immense and the little pain of using feature flags is worthwhile. Yes, developers test with all feature flags turned on, because the feature is there even though is being worked on.
Reasons for not working at Thoughtworks.
- Pair programming is like living in an Indian family, with no sense of privacy. Rarely this leads to deep work.
- Unable to understand, writing integration tests are more useful. Its like oh you want to write a sum function? First write a test.
Some devs I have worked, will write tests and assume their code works, push it to remote only to be surprised when it fails with an actual API call.
There will always be points of time where Merge Conflicts would come up, and the worst part is, its generally left upto the developer whose branch the merge failed, instead of a collaborative effort.
I mean when you have to explain to a bunch of intelligent audience what a regression test is, and how to run tests, you know its outta hands.
I found remote pair programming quite satisfying.
We didn't use the camera most of the time. We just used collaborative editing features of VSCode. Half of the time we worked individually on different parts of the feature (like boring boilerplate code) and half of the time together on the more finicky parts. We usually had the mics on, but we didn't talk much. We even used this setup when we were in the office sitting next to each other with headphones to not disturb colleagues more than necessary.
The testing stuff sounds weird. In my experience with pair/mob programming most people raise fast to a niveau where such basic issues are a thing of the past. Of course only if senior devs are not afraid to share their knowledge.
I mean, if you are stuck on something or either you are learning something from the other person or like mentoring someone. That is a different usecase.
But this continuous talking while coding, it's pretty annoying man. I mean atleast for me.
If you can do it. It's fine. But like my way of thinking isn't also right for everyone. I am probably one of those menace who really doesn't know how to fit in. But I just can't work like that.
Most of my roles have in IC genre. And I do need mentoring, I think of the ideas, write it down, discuss it with senior people or junior people depending on their expertise level. And then go along with the day.
Really nice overview… as someone who has never worked in an org that practices trunk-based development, I’m eager to join one, and one day hopefully lead a team where I get to fully explore these ideas. One thing I’ve noticed is that the sum seems to be greater than the parts, in that these ideas really bear fruit when practiced in concert with one another. It can just be so challenging to find people who are willing to try out practices that feel unfamiliar, like TDD and pair programming, even if you swear until you’re blue in the face that the best work of your career has been borne out of that type of workflow.
Talk: trunk based development makes developers happy
Meanwhile cited dora report: trunk based development significantly increases burnout 💀
That's not my experience. The main problem with burnout is in my experience management that demands agile-like velocity but prevents agile methods at every step and usually encourages competitive behavior over cooperative behavior.
Typically people that employ TBD work in a better, faster and happier way, that's also because generally teams that employ TBD also practice TDD, Pair Programming etc. If you (or DORA) want to look at which individual practice might create discomfort, then I'd agree there are plenty that when used in isolation might have inconvenient side effects, even the fictional story presented in the talk goes through several hiccups, despite practicing TBD and CI.
Trunk-based development can cause burnout when applied in places that don’t have the right safeguards to make it a smooth experience. When those practices are adopted, TBD is the best way to work. It’s continuous integration. It makes your job easier, the usage of tools less complex, it makes indeed developers happier. The best results are achieved when adopting a test-driven approach and social programming practices (pairing/mobbing).
Incidentally it is the first DORA report which Forsgren themselves did not participate in. Forsgren themselves said that something's fucky with the reports methods which made them arrive to that conclusion.
I find there is much more friction when you find some a problematic piece of released code than if you spot/were pointed out to it in the PR review. If that caused distrust in the team, there are other problems within that team. There are projects where code reviews are pointless and bring no value, in others they are priceless and save tons of money and stress. The ecosystem is just much more complicated than "let's do TDD/TBD/Scrum/whatever overhyped acronym"
You misunderstand code review to always be a separate form of activity inside a team. When pairing and mobbing the people review what is written constantly. Post-integration reviews and general codebase observations are just a great addition to that form of constant review that is done in group settings.
A bit weird how she moves from 'Big PRs are impossible to review, don't do that' to 'review whole code base/areas'. Also post-factum reviews, even though valuable, can't prevent changes before they happen. Good luck undoing some schema or infrastructure changes and while automated tests can prevent bugs they can't verify if developer understood the feature well. Local testing might not be possible besides simple unit tests and those are already understood to have limited value.
Pair programming on the other side is completely delusional IRL. It's super effective for 20min after which you become completely passive. It's also draining and impractical, even ignoring the remote work and timezone issues. Plus none of those practices is exclusive. If you pair-programmed something you can merge PR immediately together. If you can't or the peer wants to recheck it on his own screen/IDE, he can do it.
You're projecting your personal experience with pairing as an objective truth. There are tons of people who feel differently. Were your experiences with pairing done with the so called strict style pairing (i.e. rotate driver and navigator with a timer), or did you just sit down and one of you coded while the other observed?