Sketching the Management Section
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.
So, stay safe. If tidying ever breaks stuff, you’ll be tempted not to tidy, to go back to “my wizard-like powers enable me to change this messy code”.
How do you stay safe? Work in small slices. One tidying per PR isn’t a bad policy (assuming you still have PRs for tidying, we’ll get to that). “But what if getting a PR approved takes days/weeks?” Then that’s a problem to solve, not a valid reason to work un-safely.
Another topic is sequences. The tidyings stand in relation to each other. Until we have data from actual use, I can speculate on which tidyings tend to lead to which others. Explaining Variable tends to lead to Explaining Helper. Chunk Statements (should this be called “Explaining White Space?”) tends to lead to Explaining Helper or Explaining Comment. And so on.
At some point its probably a good idea to map all the tidyings and how/when/why they lead to each other. I’ll do this eventually if one of you don’t.
Another principle is maintaining the option to switch. That is, it’s valuable to be able to say, “Okay, this is enough tidying for now. I’m going back to changing behavior & I’ll get back to tidying later (or not).” If you maintain safety & keep tidying changes small, you automatically get the option to switch.
There’s the whole topic of timing. When do you tidy first? Tidy after? Tidy just because.
There’s the equally important topic of stopping. When do you stop tidying? When do you stop tidying first? After? Because? Refactoring got a bad reputation in part because programmers didn’t know when to stop. “We need 6 months of refactoring before we can add any new behavior.” “You’re fired.” It doesn’t have to be this way, but TF? better address the issue.
There’s the whole topic of incentives. Tidying is intended to be self-care, so much of the incentives are going to be internal. Tech leads & managers can create incentives either encouraging or discouraging tidying. What are common ways those with power accidentally influence tidying?
How about territory? How do you handle it when someone tidies “your” code? When you need to tidy “someone else’s” code? (The early results from the LearnerBoard are encouraging—OSS projects are accepting tidying PRs, although this may be survivorship bias. Remember your PR needn’t be accept to go on the LearnerBoard.)
That’s all I can think of at the moment. Other management-ish tidying-related topics?
__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
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