> For the complete documentation index, see [llms.txt](https://petozoltan.gitbook.io/clearcode/llms.txt). Markdown versions of documentation pages are available by appending `.md` to page URLs; this page is available as [Markdown](https://petozoltan.gitbook.io/clearcode/maintenance-cost/the-software-exists-in-time.md).

# The Software Exists In Time

Another issue that may lead to a confusing code is that we tend to ignore that our source code exists in time. I don't say we forget it but we don't take it seriously enough, with all of its consequences.

## The code is continuously changing

One of the obvious goals of software development is that the program works correctly as specified. So the definition of *goodness* is based on the correct and tested functionality.

But is it enough? Is everything we implement a *write-once-and-forget* code? What do all the software developers in the world do each and every day?

They sit down to their computers and start modifying the code. They change the code that was written yesterday or last week or last month.

{% hint style="warning" %}
They modify the program that has worked well and has been tested!
{% endhint %}

So, is the above definition still good? I think it is not. It tells only that the software works correctly *now*. So we need to extend the project goal like this:

{% hint style="success" %}
The program should work correctly now and at any time in the future.
{% endhint %}

Why is it better? Because it has the consequence:

{% hint style="info" %}
We need to implement different features with the least possible dependencies.
{% endhint %}

Unfortunately, solutions like [OOP](/clearcode/oop/do-not-use-inheritance.md), [frameworks](/clearcode/oop/what-is-the-problem-with-inheritance.md), and [common code that is not common](/clearcode/data-processing/separate-use-cases.md), create many unwanted dependencies in the code.

## Design for a long-term maintenance

Besides goodness, the other goal is the next deadline. All plans and estimations aim at the next deadline. The result is the following:

* It may lead to quick & dirty programming.
* Technical debt is collected.
* It will seriously slow down the development and put future deadlines at risk.

It will be nearly impossible to work on technical debt later since we will always work on new features and bug fixes for future deadlines.

Everybody knows that the source code should be maintainable. But if we do not *plan* it, it won't be.

{% hint style="success" %}
The goal is to maintain the software *for years*. The code must be maintainable.
{% endhint %}

As a consequence:

{% hint style="info" %}
We need to choose solutions that are easy to maintain.
{% endhint %}

And the "next deadline" sounds like a secondary goal, considering *all* deadlines during the software's lifecycle.

## Other benefits

These rules for maintainability primarily affect the development team. It is about the *ability* of the team to deliver error-free software on time for the long term. Needless to say, this affects the customer too.

But these rules have other benefits:

They work against the *burn-out* of developers who would need to work on an increasingly unmaintainable code base.

Also, they should decrease the number of developers leaving the team. Leaving developers would make the work on the project even harder and slower.