Earlier we made the assertion that “code is a liability, not an asset.” If that is true, why have we spent most of this book discussing the most efficient way to build software systems that can live for decades? Why put all that effort into creating more code when it’s simply going to end up on the liability side of the balance sheet? Code itself doesn’t bring value: it is the functionality that it provides that brings value. That functionality is an asset if it meets a user need: the code that implements this functionality is simply a means to that end. If we could get the same functionality from a single line of maintainable, understandable code as 10,000 lines of convoluted spaghetti code, we would prefer the former. Code itself carries a cost — the simpler the code is, while maintaining the same amount of functionality, the better. Software Engineering at Google
Other Authors
- Software is a means to achieve an impact: We are not working just for the software itself, but to achieve an impact on the business or mission. Code is just a tool to deliver value. Software should be seen as a means to an end, not the end itself. The outcome (the impact on users or the business) is what matters, and extra code or features beyond that are liabilities to be minimized. We must keep this in mind when making decisions and prioritizing tasks, focusing on results over output. - Software has a basal cost that must be taken into account (software can be considered a liability): Beyond the initial development effort of a feature, simply having that feature in the system incurs an ongoing cost. This Basal Cost continues until the feature is removed or the system is retired. Every feature or module adds complexity: it has to be understood by the team, maintained, integrated, and secured. When combined with the understanding that software is only a means to an end, it becomes clear that code is a liability as much as an asset. We should minimize the software we create to achieve the desired impact, delete unused code, and relentlessly manage complexity. Eduardo Ferro