Recently, I was chatting to a friend of mine who runs his own landscaping business and asked him when he had known he wanted a career in gardening. “It’s not gardening!”, he said indignantly. “It’s landscaping”.
I hadn’t meant to offend, but he explained, “There’s a big difference. We have to get the initial design right, such as terracing for example, but thereafter we have to continually watch how things play out. It’s possible we might not have judged the tree-shade properly, then things don’t grow. Or certain flowers bloom well for a while but then the beds need replacing with fresh plants. Sometimes the customer just wants to change the colour themes”.
As I listened I couldn’t help but see the parallels in software design and maintenance.
There are two aspects to this which probably deserve separate threads of thought. Firstly, in my professional career, I have often found the design of a system – its architecture – is only revealed to the team as the code is pushed, pulled and stressed by real customers. Refactoring, then, is the prelude to introducing better design or architecture as the seasons and patterns of usage become clear.
Secondly, not all code lives forever. Features are forgotten, frameworks are deprecated. The codebase is constantly under a process of renewal and replacement, much like the beds in the garden.
Programming teams refer to this as technical debt and often have a hard time justifying to business the allocation of resources to this problem. The company is looking for a constant stream of features while the programmers worry the codebase is creaking under the strain.
This is why, at NightsBridge, we coined the term “Codescaping“.
As the technical founder I was in a position to see things from both the business and technical side, knowing what it takes to maintain a codebase over many years. At some point, the TODOs have to be dealt with and more often than not the future feature set will work better if today’s code is re-worked to fit the customer patterns showing up in the logs.
The business commitment to codescaping is that we now schedule one in five sprints to the job of ‘weeding the garden’. Of course, ‘weeding the garden’ was never going to inspire programmers to tackle the problems that need fixing, while “Codescaping” is a much more powerful idea. Our goal in the codescaping sprint is to take aspects of the codebase that programmers know aren’t working optimally and refactor, replace, deprecate, phase-out, and generally re-work the code to better suit today’s and tomorrow’s requirements. Like my landscaper friend, we’re trying to look at the whole with fresh eyes, pull out what’s not working, replace the beds that have died, and generally make sure we maintain an overall theme to the garden.
Codescaping also allows the programmers time to research new technologies, giving them an opportunity to set up “Hello Worlds” without feeling guilty. It gives breathing space for the version upgrades that we know have to be done but which are just not visible to business.
Justifying codescaping to business is a lot easier if you speak the language of the other side. Most accountants will understand the concept of depreciation. It helps to explain that salaries paid to create software represent the building of capital. Whether this software capital is reflected on the balance sheet or expensed through the income statement its worth depreciates over time. Business people are used to depreciating their capital assets at say 20% a year. Why not recognise that software assets suffer from the same wear-and-tear? In this way, time and resources allocated to codescaping can be justified as a necessary capital renewal of the technology base. Our implementation of codescaping every fifth sprint is a financial recognition of this 20% depreciation.
NightsBridge has been practicing codescaping for a year. However, some improvements have been suggested. While identification and description of features are relatively well-defined concepts in product definition, we found we didn’t plan as well for the codescaping sessions. We need better systems recording what is to be done while we’re engaged in the normal sprint process. Building codescaping stories requires as much effort as those worked up by the Product teams.
A landscaped garden can be a beautiful thing. It is design imposed upon nature; a living, breathing thing needing constant care and attention. Codescaping introduces the same idea of design, care and renewal to the codebases that power our businesses.
