Code Ownership
Responsibility for quality and maintenance
Code Ownership Tips (1/2)
- Promote a culture of ownership and continuous improvement.
- Encourage developers to take pride in code quality and see debt reduction as part of their role.
- Regular code reviews, pair programming, and knowledge-sharing sessions reinforce this mindset and distribute expertise more evenly across the team.
Code Ownership Tips (2/2)
- You don't have to own everything!
- Design extensible software with clear interfaces and boundaries so that new features don't always become your team's responsibility.
- This allows other teams or contributors to build on your work without increasing your own maintenance burden.
Refactoring
Changes to the internal structure of code that improve its readability, maintainability, or design without changing its external behavior
Refactoring
- Hard to sell to non-developers
- As a developer you shouldn't have to sell refactorings—it's your job to just do them (99% of the time)
Consequences
...of not refactoring
- Broken Windows Effect: Visible signs of neglect (like unfinished migrations) can lead to further neglect and a culture of ignoring technical debt. Ref
- Lowering of standards and increased technical debt: When small issues are left unaddressed, they signal to developers that low-quality solutions are acceptable.
- This creates a feedback loop where the codebase quality steadily declines.
Consequences
...of not refactoring
- Tolerated Pain or "Annoyance Debt": Pain of the current state is acknowledged but not severe enough to justify prioritizing the fix over other work.
- Cumulative productivity loss: Over time, these small annoyances add up, leading to recurring workarounds, slower development, and increased frustration.
Consequences
...of not finishing refactorings
- Zeigarnik Effect: Our brains remember uncompleted tasks more than finished ones, increasing cognitive load.
- Mental Fatigue: The unfinished task weighs on your mind, making it harder to focus on new projects.
Consequences
...of not finishing refactorings
- Motivation Drop: When a task seems nearly complete but remains incomplete, the final steps feel tedious and motivation drops.
- Increased Stress: The unfinished task causes stress until it's finally done.
Incremental Refactoring Pitfalls
- Incremental refactorings should be preferred over big bang refactorings, BUT:
- The team can lose momentum, leaving the system in a prolonged hybrid state.
- This creates ongoing maintenance burdens as both old and new systems must be supported.
Bike Shedding
- Doing the hard and meaningful refactorings is avoided by bike-shedding.
- Example: focusing on dependency updates instead of necessary architectural improvements.
Refactoring Tips (1/2)
- Finish what you start: Unfinished refactorings create cognitive load, stress, and maintenance burdens—always complete your refactoring tasks, or at least have a clear plan and track progress if they will take a long time.
- Refactor incrementally, but avoid prolonged hybrid states: Small, incremental changes are safer, but leaving the codebase half-migrated increases complexity and maintenance effort.
Refactoring Tips (2/2)
- Don't fix what isn't broken, prioritize based on impact: Focus refactoring on areas that genuinely need improvement.
- Watch for “bike-shedding”: Don't get distracted by trivial changes at the expense of meaningful architectural improvements.
Conclusion
- Ownership and refactoring are essential for maintaining a healthy codebase.
- Promote a culture of ownership, continuous improvement, and clear communication.
- Finish what you start, prioritize effectively, and avoid bike-shedding.