> 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/consider-the-maintenance-cost.md).

# Consider the Maintenance Cost

## Software Estimation

The goal of software estimation is usually to tell this: which *specific* features can we deliver on a *specific* deadline?

But it does not consider the cost of *maintaining* the code in the long term, which spans through deadlines.

## Look at the price tag

Imagine that we want to create a financial plan for our household. We want to know how much money we have and what we can buy.

Can we create this plan so that we do not care about the prices? Can we buy anything? Can we buy a new Lamborghini? Or even worse: can we buy an old second-hand car for the price of a new Lambo?

{% hint style="info" %}
We have to look at the price tags!
{% endhint %}

We have to do this in software estimation too. 

We never involve the maintenance cost in the decision when choosing a solution. We have a blind spot on it. So we end up paying a big price for a small benefit. 

## Why does the code have a maintenance cost?

Unfortunately, the code we write is not a *write-once-and-forget* thing. We will have to modify the code in the future multiple times for some obvious reasons:

* Bug fixes. If there are errors in the code, we have to fix them.
* Change requests from the customer. We will surely get them and will have to do them.

Sadly, that's not all. The maintenance cost will get higher due to other reasons:

* The complexity of the code will increase during the frequent modifications.
* The code we write is simply not clear, and not readable enough.
* The solutions we have chosen are hard to maintain. 

These expensive solutions usually contain:

* Too many dependencies between the features that should be as independent as possible.
* Too many indirections, making the code less straightforward and less readable.

## Cost/benefit ratio

Of course, every solution we chose comes with a benefit too. But we should investigate the cost/benefit ratio before implementing it.

### Unnecessary code

There is an alarming consequence of this "formula":

{% hint style="warning" %}
The cost/benefit ratio is infinitely high for the solutions which are *not necessary*.
{% endhint %}

For example, OOP and inheritance have very high maintenance costs, while they are not necessary. See here why: [Separate Data And Procedures](/clearcode/oop/separate-data-and-procedures.md), [Do Not Use Inheritance](/clearcode/oop/do-not-use-inheritance.md)

### Overestimating the benefits

Be careful when estimating the benefit of a solution. We, programmers, are always enthusiastic about the solution itself, overestimating its benefit.

We typically create abstract, generic, and automated solutions, saying it will be good for future extensions. But they will never be good! We cannot foresee the future requirements that will enforce us to rewrite the existing code.

{% hint style="warning" %}
Do not implement a solution for unforeseen future requirements.
{% endhint %}

## How to decrease the maintenance cost?

I do not simply suggest to add the maintenance cost to the usual estimations.

Instead, we should decide whether we keep or drop a solution. Of course, this needs us to design and discuss the solutions before implementing them.

{% hint style="warning" %}
Avoid estimating the costs when it is too late—i.e. when it is already implemented.
{% endhint %}

## When and how to implement complex solutions?

More precisely when to choose a complex and expensive solution *for one specific feature within a larger software*? 

The answer is simple but it may be inconvenient:

{% hint style="info" %}
Treat complex solutions as distinct software.
{% endhint %}

* Sell it to the customer.
* Dedicate a team.
* Separate the code base.
* Specify, design, and document.
* Implement and test separately.


---

# Agent Instructions
This documentation is published with GitBook. GitBook is the documentation platform designed so that both humans and AI agents can read, navigate, and reason over technical content effectively. Learn more at gitbook.com.

## Querying This Documentation
If you need additional information that is not directly available in this page, you can query the documentation dynamically by asking a question.

Perform an HTTP GET request on the current page URL with the `ask` query parameter:

```
GET https://petozoltan.gitbook.io/clearcode/maintenance-cost/consider-the-maintenance-cost.md?ask=<question>
```

The question should be specific, self-contained, and written in natural language.
The response will contain a direct answer to the question and relevant excerpts and sources from the documentation.

Use this mechanism when the answer is not explicitly present in the current page, you need clarification or additional context, or you want to retrieve related documentation sections.