Your Lines of Code Are Not a Success Metric – InApps Technology 2022

Cloud Foundry sponsored this post.

Each line of code is more of a liability than an asset.

When you buy a home, you’re investing in an ongoing project that will keep you occupied with incremental improvements, continuous upgrades and the infrequent but requisite large-scale renovation. Developing and maintaining software is analogous to home-buying, in that you are in a constant state of flux.

A house provides shelter at its most basic and an architectural design that will appeal to inhabitants — and it’s a combination of both that makes a house worth living in. You must upkeep the structural integrity of the house to keep it standing, but you can’t neglect the aesthetics that make the house uniquely enchanting.

Likewise, software provides critical structure, tools and connections, and it must be consistently updated with new features and bug fixes that maintain its integrity and continue to make it uniquely valuable to users.

When a buyer invests in a house, they must weigh whether the property will be more of a liability or an asset. A company using a line of software code should be approaching it in much the same way. However, this isn’t always reflected in the open source community and software development at large — and if you ask me, a line of software code is more of a liability than an asset.

Superfluous software code is not a success metric.

A line of code is not a metric of a community’s success in the open source space. Enterprises of all types need to learn that the more lines of code in software, whether it’s proprietary or open source code, the more complex and expensive it is to change your project.

Using vanity metrics like lines of code is a poor method to track and share the health of your software. Vanity metrics are antithetical to proper software engineering, which is about reducing complexity and reducing lines of code. (In fact, I’d say it’s only reasonable to track lines of code if you are actively trying to reduce the number — not increase it.)

Why is a line of code more of a liability than an asset? It’s a constant source of work. Every line of code that a developer, team, company, or community has to maintain triggers extra work that must be done to keep it up to date.

Bit rot, like wood rot, can go undetected until it’s too late.

When software code is neglected and the operating system or libraries on which a line of code relies are updated, it causes a chain of events that will break integrations with other systems. This phenomenon —“bit rot” —often goes undetected until it’s too late.

Software that remains stagnant, particularly in the webspace or modern software architectures, is going to experience bit rot pretty quickly. In the wild west of distributed web systems, everything is changing all around you, so if you leave that code alone, it will rot away eventually and stop working.

Superfluous code engenders short- and long-term challenges. More lines of code open more opportunities for bit rot to occur and makes it exceedingly difficult for a developer to make modifications.

Software is valuable for a reason, but if you don’t give it the constant attention it requires, your entire operation could be barreling down a dead-end road to ruin. Think of a house with a brand new coat of paint, while wood rot eats away at its foundation. Developers and enterprises are rightfully proud of the software they’ve built, but that pride can be misguided when it becomes hard to let go of your code — even though it would require less maintenance, and therefore be less of a maintenance liability.

Pride of ownership must be tempered.

This psychology manifests in a few ways. One way is an unwillingness to cull code on a regular basis to decrease complexity. The other is known as “Not Invented Here” syndrome, in which a team of software engineers decide that external options are “not good enough” and decide to build it themselves. This afflicts both enterprises and open source communities, forcing them to spend more resources to build something that can be claimed as their own.

If software that isn’t uniquely differentiating or core to your organization’s needs can be sourced elsewhere, it should be adopted and embraced without hesitation. Developers may have to build software internally to get a project off the ground, but they need to be willing to abandon that code later on for software that is equally sufficient and — more importantly — collectively maintained by others.

If a line of code isn’t core to your mission, you should outsource it to someone who can more effectively construct and maintain it, to allow your team to focus on more important internal work. If code reuse from a generalized software project can fit into your architecture and solve that need, why not take advantage of it?

Letting go of code is an incredibly important part of this journey. Most of us don’t even consider building our own servers anymore–or our own houses. We buy a house that’s already been built and if we want to make additions, we hire a contractor to do it. When capabilities that are necessary but tangential to the mission are available as a service, enterprises snap that up. The same mindset should apply to the software layer.

Extra lines of code are not a sign of progress. Nobody should be impressed by a tenfold increase in line code. Progress is letting go of our inhibitions and reducing lines of code in software whenever possible. Consider it part of a healthy evolution of your software. Lines of code are a liability — let’s start treating them as such.

Feature image via Pixabay

At this time, InApps Technology does not allow comments directly on this website. We invite all readers who wish to discuss a story to visit us on Twitter or Facebook. We also welcome your news tips and feedback via email: [email protected].

InApps Technology is a wholly owned subsidiary of Insight Partners, an investor in the following companies mentioned in this article: Bit.