This file contains ambiguous Unicode characters that may be confused with others in your current locale. If your use case is intentional and legitimate, you can safely ignore this warning. Use the Escape button to highlight these characters.
# Infos
auth-name : naomi rosenberg
tag : refactoring, micro-management, professionalism
need travel fee : N
need room : Y
Location : Planet Earth
# How Stealth Refactoring is Wrecking our Codebases
Because management are perceived not to value refactoring, developers fear being “told off” for doing it. So we refactor less than we’d like to, and when we do, we often sneak it in, hidden amongst functional changes.
We know insufficient refactoring leads to technical debt. Stealth refactoring creates problems, too. Reviewing a diff mixing functional and non-functional changes is time-consuming and error-prone, costing money and introducing bugs. Also, stealth refactoring tends to focus only on the “geographical area” - the function, file or module - that we are “touching” at the time. What are the implications of that for the coherence and consistency of our codebases?
I will make some technical suggestions for optimising how we refactor, but the main issue is cultural. Is our shame around refactoring entirely due to management, or are devs responsible too? How can we sell simplicity to people who may not be aware of its value? Can we create a culture that legitimises - or even rewards! - a practice that is, after all, essential to developing good software?