A software team basically has two responsibilities: Build features and fix their broken-ass software. A lot of time business needs pressure the former to take precedent over the latter, and we live with that. It's called technical debt, and it's a tool like any to get software shipped.
Logically, we all know that the refactoring and edge-case clean up eventually needs to happen. But eventually can lead to never and the software rots and becomes chaotic. This things behaviors that lead us down the path of crappy, broken software are not usually "logical", they are human, emotional behaviors. Perhaps we feel too ashamed to bring up the fix of the software we wrote, or too polite to tell others. Possibly the business has stressed growth and features to the point where we just don't know where refactoring fits into the schedule. Maybe the people in charge don't even understand the concept of refactoring or technical debt, or don't want to pay for additional work to software that is "done". There are good situations, but every situation has at least a hint of these sorts of behaviors.
You may try endlessly to come up with systems to solve the issues. Trello board after Trello board assigned to the issues, ticket points, sprint cycles, on and on and on. While process is part of it, the big barrier is emotional. Refactoring code doesn't "feel" like progress. What we need are habits, personal and organizational, that reinforce the things we logically know need to get done.
Celebrate refactorings and small fixes. Celebrate them a bunch. Cheer on pull requests that tackle that code nobody wanted to touch. At your all hands meetings, take a moment to honor someone who deleted 100 lines of dead code, or wrote a critical feature test nobody wanted to write because it required mocking a really fickle endpoint. You need process, but process can't make people want to do it. If making feels great, people will do it.
Most of the time waiting for code to be perfect is a terrible habit for teams and individuals. Endlessly bikeshedding over details in the name of perfect software is an anti-pattern we want to avoid here. It is possible that applauding the fixes could take attention off of the much-needed shipping, but I would say it's the opposite. If developers know that cleaning things up in the near future is a possibility, shipping good—not perfect—code also becomes easier.
Applaud the behavior that hardens your code and makes building new features a sustainable effort.
Top comments (2)
After a stressful release I like to run static analysis, linting tools and documentation analyzers. I find it calming to see the warnings get whittled down and there's little risk to functionality - well, the way I do it. It does tend to mess with source history pretty bad though.
Loved this sentence