Maintenance costs

Last time we estimated the cost of code change, now we'll try to reveal the connection of costs and maintenance.
Let's first suppose that the company we consider does not care about improving the code, it just fulfills the customer feature requests.
Suppose that a new feature request arrives (let's denote the feature by
). If the feature is, let's say, implemented during the
time interval, then based on our earlier estimates, the cost of this feature can be expressed by the following formula:
![]() |
But if code is not being improved, by fulfilling the incoming feature requests, the maintainability of the system decreases, i.e.:
![]() |
According to the above expression, the maintainability decrease rate is proportional to the change rate of lines in the system. The coefficient
may depend on many things, like:
- System architecture (is it a framework or not?)
- How modular the system is
- Time pressure onto developers, etc.
By substituting this latter formula back into the first one, we get the following:
![]() |
which means that on one hand the cost of implementing a feature can be expressed by the logarithm of decrease rate of maintainability of the system. Yet another definition of maintainability:
![]() |
where
is the overal amount of costs spent on implementing features starting from an initial time
,
is the initial maintainability value of the system (can be set to any particular value), according to which we will get the current maintainability of the system itself. The very last conclusions follow:
- Without code improvement phases the maintainability of the system decreases exponentially as new features are added
- Cost of adding a new feature is proportional to the logarithm of the decrease rate of maintainability
- The exponential factor of the decrease rate depends on two key factors:
- the external costs of altering a line of code
- the degree of influence of code change onto maintainability
In long term efforts toward decreasing these two quantities are paid back in cost reduction of adding new features.
The model applies when no code improvement (classical maintenence) is applied during the lifecycle of a software system. Next time, we will model the effects of code improvement phases as well, which aids increasing system maintainability directly.
![$$<br />
{\cal C}_1^F[t_0,t_1]=\int_{t_0}^{t_1}{{\cal C}_L N\left(t\right)\lambda \over {\cal M} ( t )}<br />
$$](/sites/default/files/tex/33de29b9d72f04843292cd17f5927102a4c2b2fe.png)

![$$<br />
{\cal C}_1^F[t_0,t_1]=\int_{t_0}^{t_1}{{\cal C}_L N\left(t\right)\lambda \over {\cal M} ( t )}=-{{\cal C}_L \over q} \int_{t_0}^{t_1}{ \dot {\cal M}(t) \over {\cal M} ( t )}=-{{\cal C}_L \over q}\left[ ln{\cal M}(t_1) - ln{\cal M}(t_0)\right]=-{{\cal C}_L \over q} ln\left({\cal M}(t_1) \over {\cal M}(t_0)}\right)=ln\left({{\cal M}(t_1) \over {\cal M}(t_0)}}^{-{\cal C}_L \over q}\right)<br />
$$](/sites/default/files/tex/c87aaf3f2133c7addb5d9616d901d84a3f2176f4.png)
![$$<br />
{\cal M}(t)={\cal M}(t_0) e^{-q {C[t_0,t_1] \over {\cal C}_L}}<br />
$$](/sites/default/files/tex/24796dd2a867f6941fee1b35ddbbdfeba230fb05.png)













Improvement phases
I think it is very important to note, that the mentioned improvement phases should strictly separated from the feature development phases. Without that, we could face several problems:
* The features will be not developed as good like in a pure feature development phase, because the developer has to deal with the improvement as well, not just to the features. The same is true for the improvement.
* What would be the first? Features or improvements? Making it parallel just a new problem for the development.