leebyron

If the business, team, and leadership is good, then go make it right. Or really either way, if you just joined your first move should be to introduce a plan to make it right and get leadership’s input, and give them the opportunity to show enthusiastic support (stay) or disapproval (go job hunt)

Pitch:

Your team doesn’t understand the code. Signs the code is poorly organized. Typical changes take way way longer than they should. Our error rate is too high. Must rectify immediately.

Plan:

Buy a copy of “working effectively with legacy code” for each teammate. https://understandlegacycode.com/blog/key-points-of-working-effectively-with-legacy-code/

Then address in phases. Numbers illustrative; tune to your team and problem size.

First phase, 2-4 weeks, goal to have everyone understand the codebase, but no promises on improvements. This is the team’s full focus, no other work. Every teammate claims a portion of code, writes tests and does light refactoring; goal isn’t to fix, but understand. As soon as they do, they present to the team, helping everyone understand it as well, answering all questions. Then they pick a new portion and continue. Aim to have ~2 explain sessions a day, rotating through the team. Run a light retro at the end of each week to tune the process.

Next phase, 4-6 weeks, understanding will continue but now the goal is improvement. Not the full team’s focus, but a majority. Accept only 1/3 -1/2 outside workload. Pick a few key goals based on the first phase (compile time?) Tests are now a means to refactor rather than just understand. Keep team presentations going, but treat them as sequels, “now that you’ve learned about this area, here’s what I did to improve it”. Keep retros going as well.

Last phase, indefinite, maintain. You’ve spent significant time learning and improving as a team, you’ve identified plenty more to repair or you collectively still don’t understand, that’s okay! Going forward reserve ~1/4 of the team’s capacity for this in an ongoing way. Keep team presentations, but scale them back to a fixed calendar (weekly or biweekly). Explain that we’re adopting cultural principles to always improve as we go, accept that improvement is unending (see: Hedonic Treadmill, Art of Motorcycle Maintenance), and that teaching and learning from each other is part of the job.

In 3 months you’ll likely transform the team more than the code, you’ll be happy with the improvements but frustrated and hungry for more, but will have established a positive trajectory. The up front cost of pausing the team’s output will feel costly, but development time will recover and end up far faster than it started, paying back the cost quickly

No Reason - Chemical Brothers

The Final Countdown