Technical debt and the maintenance load of software are popular topics of conversation among developers. Software, by its very nature, is a living entity, but it needs active nurturing to prevent it from needing to be placed on life support.
Development teams often discuss strategies to make software more maintainable. Many of these strategies revolve around making the software observable, self-documenting, and easy to extend. There are numerous tools and workflows that have been created in an attempt to tackle the challenges surrounding codebase maintenance. Several strategies often boil down to building a culture around sustainability and maintainability.
The role that culture plays
Culture is a topic that is also widely discussed, and I think it’s tricky to get right. Some cultures form organically from how the founding team members relate to one another and their work. When new members join the team, they bring their own approaches, and things keep evolving. Sometimes, extremely negative practices take hold and it becomes difficult to address. Very similar to real life, cultural practices can be difficult to reform.
So, before the team gets too big, cultural frameworks should be formulated. Leadership should be the custodians of the cultural core, and culture should be approached with intention. Intentionally and mindfully approaching the team’s cultural practices is key. Even small things like how we communicate on Slack and how we ask for help are extremely important to be intentional about. A culture of transparent knowledge sharing is also important to be handed down from leadership. Documentation and open information transfer should be enforced, encouraged, and periodically revisited. Culture is important for a company, and also, by extension, important for a codebase.
Building a culture for software maintenance
The maintenance load should be considered in every conversation during the progress of the software. Even when the project kicks off, there should be an intentional effort to document context and decision-making. These documents should be accessible to the whole team. Any member of the team can take ownership of any aspect of the codebase, as long as they are motivated to do so.
Teams should also consider the bus factor. One person should never hold all the keys to the kingdom, because people leave teams all the time, and the biggest loss a team can face is the loss of historical context and expertise.
The maintenance load of culture
Culture should not be entirely organic. I don’t think people should be left to figure things out solely on their own. The whole team should own the culture and maintain it with intention. This requires frameworks, guides, and structured documentation. If processes are repeatable and transferable, they are easier to practise in spite of team attrition.