2026-06-06: Every Line is a Liability
"Everything is a liability" - Your Lawyer
Every line of code your organization has to maintain is a liability. Each line introduces the possibility of defects and creates a long-term commitment to support this line: developers will have to continue to read it, tests will have to continue to cover it, security scanners will run over it, etc. Of course, in exchange, you hope that this line creates revenue or reduces costs.
Of course, this is not strictly about lines, although well-structured code is usually structured as lines. It's really about statements or operations (each individual discrete "piece" of computation). One could easily create more lines and reduce liability (for example, by making your stupidity so clearly visible that future defects are reduced). Of course, reducing the number of lines very easily increases the liability (looking at all those programmers creating multi-line list comprehensions in Python: please exit your employment immediately and return to a retirement of code golfing in Perl). But the lines metaphor is more readily understood by non-technical users and most tools count in lines, not statements.
It may seem, of course, that the expensive part of programming is writing these lines, especially if you yourself do not program. The expensive part, however, lies generally in understanding what to write in the first place. This understanding does not come neatly, and one cannot comprehend the entirety of the written solution before engaging in the act of writing it (unless of course such a thing is trivial). Understanding the correctness of a solution comes from building a mental model, and this mental model cannot be built effectively beforehand (otherwise we could simply document anything we wanted, and have developers read it).
Product success largely depends on developing a concrete, coherent, and consistent model of the product. At different scales (or granularities) this manifests itself in different ways. Developers concern themselves with programs (and their architecture), product managers with their capabilities, sales people with their solutions, etc. For developers, each added line represents (hopefully) a step towards these three C's, so that valuable business product is delivered by the product team, so that the sales team can sell, or operations can operate, etc.
More features does not imply more business value. In fact, a great number of features go unused, and in the worst case they limp along as zombies (zombies that each money, because code has costs as long as it exists). In some cases, more features actively harm business value, and not just from a code perspective! Your sales team likely cannot sell (or demo) a confusing, incoherent, and inconsistent set of features (in fact, a pile of ill-thought out features likely fails to meet the definition of a product in any case). Users of your system (internal or external) will likely waste time or make mistakes with poorly designed software. In this way, more features = more lines = more problems (and not more money, but less).
More lines also often represent a certain kind of "code smell", which usually indicates that your code is duplicated. Duplicating commonly used routines, or functions from external libraries, or implementing bespoke copies of sorting algorithms, or even just duplicating other parts of your codebase because you did not bother to search for the function that already exists that you need to add all raise your maintenance burden. Re-implementing common algorithms runs a very high risk of introducing bugs (for example, it is well known that you should never "roll your own crypto") or performance problems. Which has a cost in terms of user experience, performance, security, and maintenance.
Duplication is not always or entirely problematic, and there are valid reasons for duplication. Many developers fight too hard against it, even, and produce abstractions which attempt to force various superficially similar pieces of code into a common routine, which usually ends up as a function of a dozen arguments (also usually a bad sign). Duplication should be undertaken thoughtfully. It should also come with an understanding about how to remove it, if said duplication is meant to be temporary.
Technical debt has along been understood as a burden, as a cost (even if that cost has been viewed as too low). Technical debt exists because lines of code (bad lines of code!) exist. The usually solution to technical debt is removing these lines of code, often replacing them with newer, shinier, and less numerous lines of code. The goal being to reduce the long term maintenance burden and often to make delivering future features faster and easier.
Unfortunately, in these trying times that we live in, AI has introduced the ability to crap out an enormous number of lines of code (in addition to all manner of nonsense, like documentation slop). This has both very significant short term and long term costs, if not very carefully monitored.
Unless your developers are extremely diligent, your team will be drowning in huge, hard-to-understand, and likely defective pull requests.
Your developers are not extremely diligent. If they were, you would have seen this clearly manifesting itself earlier on in history. For example, they would be reading the tickets assigned to them. Or checking if their code works before creating a pull request. Or that it meets the acceptance criteria. They might have been creating documentation. Or advocating for the reduction of tech debt.
The work is hard. Good work is very hard. There is a mental burden, a tax, that comes with doing this work in the right way. One might say, that you need to suffer, a necessary but not sufficient condition for success.
Are developers lazy? Not any more or any less than anyone else. People want to get to the end goal (for example, for a developer, having their ticket merged) as quickly and as a easily as possible. This is why new tools, new languages, new techniques, etc. continue to be developed, because people are trying to reduce the amount of effort or time to get to some stated goal (the old adage of "true laziness is hard work" comes to mind).
Given the option, anyone will try to take a shortcut. For developers, that means copying and pasting the ticket into an LLM, often with some additional prompts, and hoping the result is a pull request that can be merged.
Product teams are under more pressure than ever to deliver more quickly, and this pressure flows down to developers. Of course, delivering more does not mean more value. Without any specific tie-in to revenue or savings, developers, product managers, and the entirety of your business outside of sales is operating off some proxy metric. "Chart go up" (or maybe down) is what managers and executives are monitoring, and very often they are not considering in totality the value of the work to the overall business (admittedly, tying work to business value is very hard, so a level of reductivity is a requirement).
Organizations should be very conscious of the number of lines they are creating. Historically, it was considered good (and in some cases, important) by leadership that the number of lines of code go up. Today, in addition to the metrics everyone is already tracking (velocity, defect rates, uptime, etc.), lines of code must be tracked. This, as with all metrics, must be done with a measure of consideration, of understanding, as it is trivially easy to game this metric. Organizations that fail to track and control the number of lines they are adding are likely ingesting enormous amounts of AI slop. This is creating both short term and long term burdens on their business.
Every line is a liability is even more true today than it ever was. Despite the mechanical act of making lines being now cheap, huge burdens exist in making them correct, and in ensuring they form a coherent, consistent, and concrete product.
Previous: 2026-05-29: Latency in Communications