Maintainable software enables easy modification and prevents unnecessary complexity and bugs.
Codebases become unmaintainable when technical debt accumulates and leads to complexity and duplicated code.
Choosing the right technology, language, and processes can improve codebase maintainability.
Deep dives
The Importance of Maintainable Software
Maintainable software is crucial for the long-term viability of a codebase. It ensures that the software can be easily modified, extended, and fixed without introducing unnecessary complexity or bugs. Codebases that are difficult to maintain often lead to longer development cycles and a decrease in productivity. It is essential for developers to understand the importance of maintenance and actively work towards making their code maintainable.
Gradual Transition to Unmaintainable Code
Codebases gradually become unmaintainable when technical debt is not properly addressed. Technical debt, which is necessary in the short term to deliver features quickly, can accumulate if not taken care of. This debt eventually leads to codebases that are hard to understand, modify, and extend. As the debt mounts, the codebase becomes more complex, with inconsistent and duplicated code, making it increasingly difficult to maintain.
The Distinction between Maintainable and Good Code
There is a distinction between maintainable code and good code. Maintainable code focuses on readability, simplicity, and adherence to best practices to enable easy modification and extension. Good code, on the other hand, is subjective and can vary depending on personal preferences and available resources. While maintainable code is often considered good code, there can be instances where code is well-written but not easily maintainable.
The Role of Technology in Maintainability
Choosing the right technology and language can greatly contribute to the maintainability of a codebase. Languages like Go, which prioritize simplicity, readability, and enforce coding standards, can make codebases more maintainable. Additionally, proper documentation, clear coding conventions, and processes that facilitate codebase transitions can also improve maintainability. Technology plays a crucial role in facilitating the maintainability of software.
Maintainability and the Subjectivity of Code Bases
Maintainability of code bases is a subjective concept that evolves over time. What is considered maintainable is based on what can currently be done with the code and whether it can be sustained in the future. Similar to the concept of simplicity in writing, maintainability is difficult to define precisely but can be felt when working in a code base. Different factors such as code complexity and adherence to best practices can impact maintainability. While it is subjective, engineers can develop a sense of what feels maintainable based on their experiences and the ability to understand and navigate the code.
Approaching a More Scientific Method for Maintainability
While maintainability is subjective, there are efforts to introduce more scientific approaches in evaluating it. The use of tools like linters and static analysis can provide immediate feedback on code quality. Establishing common patterns, best practices, and style guides can also contribute to more maintainable code. However, what is considered maintainable can vary depending on programming languages, specific code bases, and even individual teams. It is important to strive for a balance between defining objective standards and allowing room for subjectivity to account for different contexts and preferences.
This week we’re sharing the most popular episode of Go Time from last year — Go Time #196. We believe this episode was the most popular because it’s all about building actually maintainable software and what goes into that. Kris Brandow is joined by Johnny Boursiquot, Ian Lopshire, and Sam Boyer. There’s lots of hot takes, disagreements, and unpopular opinions.
This is part two of a three part mini-series led by Kris on maintenance. Make sure you check out Go Time #195 and Go Time #202 to continue the series.
Changelog++ members save 6 minutes on this episode because they made the ads disappear. Join today!
Sponsors:
InfluxData – All of the open source software InfluxData creates is either MIT-licensed or Apache2-licensed. These are very permissive licenses. But why are they all for permissive licenses? Paul Dix shares his thoughts on the spirit of open source and why freedom, evolution, and impact drive them to license InfluxData’s open source software as permissively possible. Learn more at influxdata.com/changelog
Square – Develop on the platform that sellers trust. There is a massive opportunity for developers to support Square sellers by building apps for today’s business needs. Learn more at changelog.com/square to dive into the docs, APIs, SDKs and to create your Square Developer account — tell them Changelog sent you.
Honeycomb – Guess less, know more. When production is running slow, it’s hard to know where problems originate: is it your application code, users, or the underlying systems? With Honeycomb you get a fast, unified, and clear understanding of the one thing driving your business: production. Join the swarm and try Honeycomb free today at honeycomb.io/changelog
Retool – The low-code platform for developers to build internal tools — Some of the best teams out there trust Retool…Brex, Coinbase, Plaid, Doordash, LegalGenius, Amazon, Allbirds, Peloton, and so many more – the developers at these teams trust Retool as the platform to build their internal tools. Try it free at retool.com/changelog
