> After a period of time, your tech team is unable to ship fast enough and sometimes even your basic hygiene factors like uptime are suffering. “Refactoring” becomes a rallying cry instead of shipped.
This hits close to home. Every death spiral I’ve seen has had a phase where “refactoring” seemingly becomes the primary activity of the team.
Some of this is refactoring is necessary: When inexperienced engineers write the wrong structure at first and need to correct it. However, much of it is arguably unnecessary: Engineers “refactoring” code to make the system more their own creation than someone else’s work, or simply rewriting old code because it’s easier to revisit familiar old code with the benefit of hindsight than it is to write new code with new challenges.
I once inherited a failing project with a team of engineers 3-4 turnovers removed from the original authors. They were burnt out from being busy all the time, but they couldn’t actually point to any new features or even improvements they had shipped recently. It was all just “refactoring” to complete an architecture change that had been started by previous engineers who left. At that point, nobody who remained actually knew why the giant refactor was started or what benefit it was supposed to bring. They were just “refactoring” old code to match a new style that a departed lead has preferred. Madness.
This hits close to home. Every death spiral I’ve seen has had a phase where “refactoring” seemingly becomes the primary activity of the team.
Some of this is refactoring is necessary: When inexperienced engineers write the wrong structure at first and need to correct it. However, much of it is arguably unnecessary: Engineers “refactoring” code to make the system more their own creation than someone else’s work, or simply rewriting old code because it’s easier to revisit familiar old code with the benefit of hindsight than it is to write new code with new challenges.
I once inherited a failing project with a team of engineers 3-4 turnovers removed from the original authors. They were burnt out from being busy all the time, but they couldn’t actually point to any new features or even improvements they had shipped recently. It was all just “refactoring” to complete an architecture change that had been started by previous engineers who left. At that point, nobody who remained actually knew why the giant refactor was started or what benefit it was supposed to bring. They were just “refactoring” old code to match a new style that a departed lead has preferred. Madness.