The Scouts have a rule: “Always leave the campsite cleaner than you found it”. In other words, if you find a mess, clean it up, no matter who made it. In his book, ‘Clean Code’, co-author of the Agile manifesto and leading American programmer – Robert C. Martin (AKA Uncle Bob) – took this principle and applied it to software development. It’s a useful rule to keep technical debt under control, but not easy to follow. Here’s why.
Why a ‘clean’ codebase matters
When your business relies on custom-built or modified software and those services do what you need them to do, what difference does it make whether you have a ‘clean’ codebase or not? Well, as we’ve explored in previous blogs on technical debt, it matters a lot. Over time, the accrual of technical debt can negatively impact your business and put mission-critical systems at risk.
Rather than waiting to perform one huge, time-consuming, and expensive refactoring project, it’s much better if your developers perform regular, incremental clean-ups of the codebase, leaving it cleaner than when they found it. Whenever there’s a business need to change part of the codebase, there’s also an opportunity for developers to clean up the code, leaving it cleaner and more maintainable for the next person. In other words, they follow the Scout’s rule.
This approach makes it easier to maintain and much more appealing for the next developer to come along and work on the code. From a business perspective, it ensures the security and maintainability of critical systems.
A codebase is not a campsite
The Scout’s rule seems simple enough to follow and apply to software engineering. So why is it so rarely implemented by developers? Here’s why: Scouts don’t visit a campsite with the express purpose of modifying or improving it. Unlike software engineers working on a codebase, scouts go there to enjoy themselves, spend a night, and move on to the next site (cleaning up the mess afterward). They have no intention of changing the place.
In stark contrast, developers normally visit a place in the codebase with the explicit intention of modifying it. They’re not visiting to have fun; they’re visiting to change stuff. And their work doesn’t just impact one section of the codebase. It’s connected to (and impacted by) other locations as well. That means multiple areas might need cleaning for there to be a broader benefit to the whole system.
So does this mean this Scout rule is bad advice for devs? Definitely, not! Most people would agree that it’s good advice to leave a place better than you found it. The problem is, it’s just not that easy. The key word here is ‘balance’. Yes, leave it better as you found it. But don’t overdo it. If you’re a developer, don’t start refactoring adjacent modules in your codebase, simply because you think that while you’re there you can easily fix it. You won’t hit your deadlines. Instead, carefully manage short term business needs and long term tech debt.
Leave it better than you found it
To manage and monitor the threat of technical debt within a whole system – as well as its component parts – you need a way of surfacing independent fact-based insights into software quality. That way, as a software manager, you get a ‘before and after’ picture.
This can be useful if, for example, you bring in an offshore team to work on a short term project. In this scenario, one metric that may be of interest is the number or type of dependencies – the level of reliance on other components to function properly. More dependencies can lead to a less robust codebase.
Another way in which technical debt can accumulate is if developers deviate from the software architecture because they lack an overview and understanding of the whole software. Sometimes quick and dirty work is needed to hit a development goal.
In the name of speed, developers might add unwanted dependencies and unplanned technical debt. In scouting terms, that equates to leaving litter rather than cleaning it up. This leads to additional and unnecessary clean-up costs for software and campsite owners.
Discover an easier way to monitor your codebase to keep it clean, maintainable, and free from high-levels of technical debt. Contact a specialist at BonCode. Book a call
