I’m not quite ready to start writing the management section, so I thought I’d ramble a bit here and listen to the feedback from y’all. You’ve read (and practiced applying, remember the LearnerBoard?) the tidyings. Being good at the mechanics lowers the risk that you won’t tidy & increases the chance that you’ll stay safe. That’s really the first principle, stay safe. Sometimes I’ll tidy 2-3 times just for practice if what I’m doing doesn’t feel quite safe.
Mar 11, 2022·edited Mar 11, 2022Liked by Kent Beck
__TLDR;__
As Manager, I
- discourage tidying when the team has low business knowledge on the product
- encourage tidying first when that code is strictly related to the delivery
- encourage tidying later when the code was detected during a delivery but not straightly related.
__Long Version;__
I would like to share with you my latest experience leading a product team, and how I felt in some situations that I needed to incentivize to do some tidying and when I needed to discourage it. We have the following context:
We started around 9 month ago, a part of the product was mainly being developed by an external consultancy firm. As the product gain more business relevancy, we decided to start adding organization attention, moving from outsourcing that part into adding more developers from the company.
At the beginning, I was discouraging "huge efforts" on tidying. I felt that people were able to spot several sections on the code that could be improved, yet unable to apply safe tidying due:
1. Not understanding the product and the businesses processes
2. I tend to see people blaming the code because it doesn't match what they are familiar with
When feeling that you don't know about the code and the context, I found that people feel more secure if they adapt the code to what they know, either folder structure or main patterns being used. Indeed, I did this in the past for the same reason.
I consider applying tidies too early lead into the "full refactors", which it's, in my humble opinion, a way to explore the project and gain business knowledge.
So, instead, I discourage dedicate time on them and focus on the businesses and understand them. Helping the team define and understand the ubiquitous language first.
Some time passes. We define new features, experiences and process flows. Team starts being more confident on the source code, and mainly because they created it aside from the legacy code.
They still share their concerns about the code. Their argues move from this is not well coded to this do not represent our business model and therefore has several technical complexities and they are overcoming by avoiding that zone of the code since it's complicated to understand/maintain and slow to modify.
👆 This is a hint to me that we are not applying enough tidies because we are avoiding that zone by creating a new parallel structure aside of the previous or a super structure on top/around of the previous (our case).
In this moment, I see we might need to be more focused on tidying when some uses cases touches those areas. I start incentivizing the team to have conversations about it and aim to see if they can do some tidying incrementally (saying "incremental tidying" seems a redundancy 🤣 )
> Why are we unable to improve the code? What is happening that's preventing us to improve that zone of the code? Based on what you learned, do you think we can reduce the accidental complexity?
--------
As a manager, I think the one of the very few situations I discourage tidying early is when the team members have few to non business knowledge and it can let into several assumptions and applying tidies everywhere without a proper business focus.
This is for a small period of time. When the team has this business focus and mission driven, I tend to encourage them to do tidy first when that tidy is directly related to the business impact that we want to achieve. I also encourage them to take notes of the zone that might need tidying but that's not straightly related to what they are working now. Here it might be good tidying after.
That does help. Thank you. Whether or not to tidy first is a tradeoff. That's one of the lessons of TF? What's on each side of the tradeoff is also one of the lessons. Your heuristic of "minimize tidying while your knowledge is low" is an interesting one. Part of me wants to say, "But tidying is how I learn." But also, changing (for example) a bunch of names and then later having to change them again is also wasteful *if there is a better way*.
Mar 11, 2022·edited Mar 11, 2022Liked by Kent Beck
On our case, we had some Product Manager rotation, and the code didn't represent the actual domain model.
I intended to minimize learning the wrong thing. Otherwise we would adopted:
- Wrong naming.
- Wrong understanding of what the product should do and it's actually doing.
Doing tidying without the that context might let into the false sense of "now I understand this", inhibiting people to do a lot of questions and losing the power of staying curious to explore and have this conversation because "we don't want to seem stupid" when joining a new team and context.
Another situation is where those decisions haven't been properly documented, and people left with that knowledge. It also discourage me to take more risk at the early beginning.
I think that's another insight to you that I just realized. Because I also had a low context and knowledge, I felt discouraged to take a higher risk because:
- If something break, I cannot help the team on understanding what's correct.
As a manager, discouraging or incentivizing tidying can be related to our "confidence" when leading the team. If I'm also new to a team, I want as few pieces moving as possible until we know what we need to do.
I think it has more to be with me and my state and emotions towards the project 🤣
To be honest, we need both: Tidied Code and new functionality. This means that you should develop a clear and easy view in your team to balance between functional changes and tidying up the code. Therefore, I like the idea to couple certain tidyings to a functional PR: Then new functionality comes always with tidying - assumed that the tidying affects the same code area.
Now that sounds like a lot ;-) But is it so different from working in your workshop? Preparing and tidying up the workplace usually takes more time than the actual work...
And that goes also well with the way you enhance your system: If you make a big change, you should tidy a larger part. If you take small steps, then you clean up the little things - also depending on what you dare to do.
To establish and incentify this, I would propose two recommendations:
1. Be consequent within your team when reviewing your PRs and have look on both, functional change and tidied code.
2. Introduce metrics, e.g. new code and tidied code. I know that this is hard to measure, but teams are creative ;-)
Good ideas. I've found it's a lot less difficult to measure new vs. tidied code currently than it has been in the past, and I'd agree that an incentive there would go a long way.
> "Assuming you still have PRs for tidying, we’ll get to that"
I'm definitely interested in hearing more on this, as this has been a point of tension in the team I'm currently on. If I include tidyings in a feature merge request then I tend to get pushback saying that makes reviewing the feature change more challenging. If I put tidyings in separate merge requests (ie the MR is just some tidying/refactoring) then those tend to not be reviewed promptly which impedes progress on the related feature as often the tidying is to make the feature addition easier (ie "make the change easy, then make the easy change").
This is a dynamic I've seen also. "PR latency" is an incentive. If my PRs are instantly accepted, then I am encouraged to do lots of little PRs. If tidying PRs are accepted slower than behavioral PRs, then I'm incentivized to lump them together. If lumped PRs are discouraged, then I'm incentivized not to tidy at all. How can your team move towards instant acceptance of tidying PRs? If not everyone agrees on the value of tidying, that seems to be the issue that needs to be addressed. All of this falls clearly in the management section.
The discussions so far have had an assumption on PR reviews as the way to adress the (at least) four eyes principle, but what about pair programming and trunk-based development/continuous integration to streamline the review process? These practices are not globally applicable (e.g. most OSS projects), but when they are they can enable enhanced flow and more fluid and coherent changes.
About territory. IME It is essential to have a shared territory with a common "language" and "grammar" to which everyone can contribute. We have a common "grammar" that we share and build together. Communication & discussions are essential.
> What are common ways those with power accidentally influence tidying?
Our approach has been to use measurement that incentivizes each developer to find opportunities to tidy early and often as long as it is a change accompanied by tests (specific details on measurement mechanism at https://www.gitclear.com/line_impact_factors). It's not exactly an incentive from management standpoint, since managers can't filter on an individual's Line Impact (too much potential for misinterpretation or metric misuse), but as an individual contributor it's so affirming for me to see a graph move up when I tidy legacy code in the ways you've described.
> How about territory? How do you handle it when someone tidies “your” code?
If not for tidying the code of others, then every time a person leaves a company, you inherit a benign tumor of code that will never get tidied. So it seems quite essential to strive for an environment that encourages tidying regardless of author. Easier said than done though, I can imagine raising my eyebrows if I wrote code that got "tidied" with a set of rules I didn't agree with.
The most burning question I would like to hear opinions on: can it be proved that regular tidying is the answer to the conundrum "the bigger the repo, the more time to change it"? In theory it would seem that if that repo had stayed tidy throughout its development, it would not lose velocity as it aged. Do you think that's true, and could you imagine any way to prove it if so?
Asking since I might take a stab at trying to prove or disprove it, if nobody else will.
Repo size has many contributing factors, two being intrinsic and extrinsic complexity. Tidying and, more broadly, refactoring address extrinsic complexity. Intrinsic complexity tends to grow steadily with the age of a repo to address functionality demands, growing awarrness of crossfunctional requirements and organizational disfunction when it comes to trimming functionality. All this to say that tidying, refactoring and competent design choices cannot flaten out the development cost, but simply dampens the slope.
__TLDR;__
As Manager, I
- discourage tidying when the team has low business knowledge on the product
- encourage tidying first when that code is strictly related to the delivery
- encourage tidying later when the code was detected during a delivery but not straightly related.
__Long Version;__
I would like to share with you my latest experience leading a product team, and how I felt in some situations that I needed to incentivize to do some tidying and when I needed to discourage it. We have the following context:
We started around 9 month ago, a part of the product was mainly being developed by an external consultancy firm. As the product gain more business relevancy, we decided to start adding organization attention, moving from outsourcing that part into adding more developers from the company.
At the beginning, I was discouraging "huge efforts" on tidying. I felt that people were able to spot several sections on the code that could be improved, yet unable to apply safe tidying due:
1. Not understanding the product and the businesses processes
2. I tend to see people blaming the code because it doesn't match what they are familiar with
When feeling that you don't know about the code and the context, I found that people feel more secure if they adapt the code to what they know, either folder structure or main patterns being used. Indeed, I did this in the past for the same reason.
I consider applying tidies too early lead into the "full refactors", which it's, in my humble opinion, a way to explore the project and gain business knowledge.
So, instead, I discourage dedicate time on them and focus on the businesses and understand them. Helping the team define and understand the ubiquitous language first.
Some time passes. We define new features, experiences and process flows. Team starts being more confident on the source code, and mainly because they created it aside from the legacy code.
They still share their concerns about the code. Their argues move from this is not well coded to this do not represent our business model and therefore has several technical complexities and they are overcoming by avoiding that zone of the code since it's complicated to understand/maintain and slow to modify.
👆 This is a hint to me that we are not applying enough tidies because we are avoiding that zone by creating a new parallel structure aside of the previous or a super structure on top/around of the previous (our case).
In this moment, I see we might need to be more focused on tidying when some uses cases touches those areas. I start incentivizing the team to have conversations about it and aim to see if they can do some tidying incrementally (saying "incremental tidying" seems a redundancy 🤣 )
> Why are we unable to improve the code? What is happening that's preventing us to improve that zone of the code? Based on what you learned, do you think we can reduce the accidental complexity?
--------
As a manager, I think the one of the very few situations I discourage tidying early is when the team members have few to non business knowledge and it can let into several assumptions and applying tidies everywhere without a proper business focus.
This is for a small period of time. When the team has this business focus and mission driven, I tend to encourage them to do tidy first when that tidy is directly related to the business impact that we want to achieve. I also encourage them to take notes of the zone that might need tidying but that's not straightly related to what they are working now. Here it might be good tidying after.
-----
Verbose but I hope it helps you somehow :D
That does help. Thank you. Whether or not to tidy first is a tradeoff. That's one of the lessons of TF? What's on each side of the tradeoff is also one of the lessons. Your heuristic of "minimize tidying while your knowledge is low" is an interesting one. Part of me wants to say, "But tidying is how I learn." But also, changing (for example) a bunch of names and then later having to change them again is also wasteful *if there is a better way*.
On our case, we had some Product Manager rotation, and the code didn't represent the actual domain model.
I intended to minimize learning the wrong thing. Otherwise we would adopted:
- Wrong naming.
- Wrong understanding of what the product should do and it's actually doing.
Doing tidying without the that context might let into the false sense of "now I understand this", inhibiting people to do a lot of questions and losing the power of staying curious to explore and have this conversation because "we don't want to seem stupid" when joining a new team and context.
Another situation is where those decisions haven't been properly documented, and people left with that knowledge. It also discourage me to take more risk at the early beginning.
I think that's another insight to you that I just realized. Because I also had a low context and knowledge, I felt discouraged to take a higher risk because:
- If something break, I cannot help the team on understanding what's correct.
As a manager, discouraging or incentivizing tidying can be related to our "confidence" when leading the team. If I'm also new to a team, I want as few pieces moving as possible until we know what we need to do.
I think it has more to be with me and my state and emotions towards the project 🤣
Timing.
New code over an good design: first I write and then I perform the refactoring.
New code over old code that I don't understand or is hard to work with: tidy first.
I do the initial cleaning as much as I can to work without major problems and then I re-factor anyway along the way and at the end
To be honest, we need both: Tidied Code and new functionality. This means that you should develop a clear and easy view in your team to balance between functional changes and tidying up the code. Therefore, I like the idea to couple certain tidyings to a functional PR: Then new functionality comes always with tidying - assumed that the tidying affects the same code area.
Now that sounds like a lot ;-) But is it so different from working in your workshop? Preparing and tidying up the workplace usually takes more time than the actual work...
And that goes also well with the way you enhance your system: If you make a big change, you should tidy a larger part. If you take small steps, then you clean up the little things - also depending on what you dare to do.
To establish and incentify this, I would propose two recommendations:
1. Be consequent within your team when reviewing your PRs and have look on both, functional change and tidied code.
2. Introduce metrics, e.g. new code and tidied code. I know that this is hard to measure, but teams are creative ;-)
Good ideas. I've found it's a lot less difficult to measure new vs. tidied code currently than it has been in the past, and I'd agree that an incentive there would go a long way.
> "Assuming you still have PRs for tidying, we’ll get to that"
I'm definitely interested in hearing more on this, as this has been a point of tension in the team I'm currently on. If I include tidyings in a feature merge request then I tend to get pushback saying that makes reviewing the feature change more challenging. If I put tidyings in separate merge requests (ie the MR is just some tidying/refactoring) then those tend to not be reviewed promptly which impedes progress on the related feature as often the tidying is to make the feature addition easier (ie "make the change easy, then make the easy change").
This is a dynamic I've seen also. "PR latency" is an incentive. If my PRs are instantly accepted, then I am encouraged to do lots of little PRs. If tidying PRs are accepted slower than behavioral PRs, then I'm incentivized to lump them together. If lumped PRs are discouraged, then I'm incentivized not to tidy at all. How can your team move towards instant acceptance of tidying PRs? If not everyone agrees on the value of tidying, that seems to be the issue that needs to be addressed. All of this falls clearly in the management section.
The discussions so far have had an assumption on PR reviews as the way to adress the (at least) four eyes principle, but what about pair programming and trunk-based development/continuous integration to streamline the review process? These practices are not globally applicable (e.g. most OSS projects), but when they are they can enable enhanced flow and more fluid and coherent changes.
About territory. IME It is essential to have a shared territory with a common "language" and "grammar" to which everyone can contribute. We have a common "grammar" that we share and build together. Communication & discussions are essential.
> What are common ways those with power accidentally influence tidying?
Our approach has been to use measurement that incentivizes each developer to find opportunities to tidy early and often as long as it is a change accompanied by tests (specific details on measurement mechanism at https://www.gitclear.com/line_impact_factors). It's not exactly an incentive from management standpoint, since managers can't filter on an individual's Line Impact (too much potential for misinterpretation or metric misuse), but as an individual contributor it's so affirming for me to see a graph move up when I tidy legacy code in the ways you've described.
> How about territory? How do you handle it when someone tidies “your” code?
If not for tidying the code of others, then every time a person leaves a company, you inherit a benign tumor of code that will never get tidied. So it seems quite essential to strive for an environment that encourages tidying regardless of author. Easier said than done though, I can imagine raising my eyebrows if I wrote code that got "tidied" with a set of rules I didn't agree with.
The most burning question I would like to hear opinions on: can it be proved that regular tidying is the answer to the conundrum "the bigger the repo, the more time to change it"? In theory it would seem that if that repo had stayed tidy throughout its development, it would not lose velocity as it aged. Do you think that's true, and could you imagine any way to prove it if so?
Asking since I might take a stab at trying to prove or disprove it, if nobody else will.
Repo size has many contributing factors, two being intrinsic and extrinsic complexity. Tidying and, more broadly, refactoring address extrinsic complexity. Intrinsic complexity tends to grow steadily with the age of a repo to address functionality demands, growing awarrness of crossfunctional requirements and organizational disfunction when it comes to trimming functionality. All this to say that tidying, refactoring and competent design choices cannot flaten out the development cost, but simply dampens the slope.