Early in my software engineering career, a senior engineer at Microsoft told me “the best solution is one that requires no new code.” At the time, I thought this was nonsense. Is not my role as a software engineer to write code? Why would writing less or no code be better? More code means more bug fixes, more features, more services, and more tools. So why is more not always better?

Fast forward to 2023 – now I am the most senior engineer on a team, and I give the same guidance. Prefer solutions that require less or no code.

What led to this shift in perspective? It boils down to this: writing code is a one-time cost, but maintenance is an ongoing cost. Maintenance of successful code will extend for years beyond your original projections because migrating to a new thing will have its own cost. So, your code will run until the benefit of removing it outweighs the cost of refactor or migration.

On the one hand, this can be exciting. Your legacy could be a system the lasts for years, even decades. But on the other hand, you may live to regret introducing it in the first place, especially if your code ends up having problems. And more often than not, code will have problems after it is first written. Many problems appear immediately, but others creep in slowly as the system around it changes.

Another thing shifted, too – I see now that software is a means to an end, but not the end itself. I was especially blind to this because my first job was building an open-source framework at Microsoft. The code was the product, or so I thought. Now I realize our product was an intermediate ingredient. The framework on its own produces no value. It gained value by helping other developers solve problems will less code of their own to maintain.

Hidden costs

Ongoing maintenance costs can be hard to understand when you are learning to build software. Often your initial tasks are to write something new. Also, often young developers do not stay on projects long enough to see the consequences of their work play out.

However, with time, most engineers end up maintaining code they or someone else created long ago. And when that happens, what was hidden now becomes a headache.

We have a term for this: “technical debt”. It’s sometimes used as a dirty word to malign a system or piece of code because its issues are more expensive than they should be or preventing you from accomplishing something.

Open-source and sticky ownership

It should come as no surprise that if you make code open-source, you are giving it away for free. GitHub has tried to set up “sponsorship” programs to fund developers. I have been lucky to have some sponsors, but despite their generosity, I have earned 10 to 15 cents per hour of effort spent.

In professional environments, maintenance is passed along employees rotate through a project. In personal, open-source projects, there is almost never someone else working on it. So, ownership of your code will stick to you forever.

So, I add double emphasis to “write less code” if you are considering open-sourcing it. While open-source has benefits to the world of software as a whole, most of the benefits are collected by the big companies and not individuals. For an individual getting started, something other than money must motivate your open-source work if you want it to continue. Consider your motivations, and whether those will change over time.

An example

Five years ago, I uploaded a project called DotNetCorePlugins and advertised in Twitter with a blog post “Introducing an API for loading .dll files”. My motivations at the time were related to my work in the @dotnet project at Microsoft. I saw many developers struggling with dynamic loading. I had found one solution that was not straightforward to discover, but once I found I could abstract some complexity of .NET in a library, it seemed like a good chance to promote my findings (and my reputation) but posting online.

Since that time, however, several things occurred which I did not anticipate.

  1. There were bugs. The project has 160 issues. I made 4 releases after the initial release to address the biggest ones, but the bug reports continued to come in.
  2. .NET added a standard library feature which filled the need, but people kept using my project.
  3. I lost interest in C# and .NET. Plus, life changed. I aged, I started a family, I developed non-computer hobbies.

Now, years later, I am deprecating the project and alerting developers this has hit the end of its life. I posted the project was in maintenance-only mode in 2020, and no one has come along to offer help or to take ownership.

Write code responsibly

If you are about to write some code, you should also ask yourself:

  • Who is this code for?
  • Who will maintain it?
  • Is there existing code I can repurpose or use instead?

Writing code is fun, so keep doing it. Just be careful not to get carried away and neglect to consider its future.