Don't change the code!

bakotat képe

Earlier we've seen a model which estimates development costs and relates them to the maintainability of a system. We've also provided an alternative definition of maintainability (let's call it relative maintainability) which is not an absoulte value (contrary to most of the existing definitions), but it's value is particular at the beginning and it's change depends only on how the code has been changing. In the previous sections we've assumed that the code is changing continuously, always at the same rate, while the maintainability is decreasing exponentially with respect to the cost being "fetched" into development. It is important that until now we have focused only on the developments which aim implementing new features and they do not target maintainability improvement explicitly. In this part we'll try to shed some light on how the cost and maintainability change with respect to time.

So, we've stated that if the code is not being improved, it's maintainability is changing, and this change can be expressed by the following formula:

$$<br /> \dot {\cal M}(t)=-q N(t) \lambda,<br /> $$

where $ \lambda $ is the rate of code change, and it is assumed to be constant (at least for now).
By integration, and by assuming that $ N(0)=0 $ (i.e. the code size was zero at the beginning), we get to the following:

$$<br /> {\cal M}(t)={\cal M}(t_0)-q \lambda N(t).<br /> $$

For the size of code we may assume that $ N(t) $ > $ 0, (t $ > $ 0) $ and $ {\dot N}(t) \geq \epsilon $ > $ 0, (t \geq 0) $, i.e. code size is greater than zero, and it is continuously increasing by even a very small increase rate ($ \epsilon $).
By substituting the latter relation into the former one, we get the following:

$$<br /> {\cal M}(t)={\cal M}(t_0) - q \lambda N(t) \leq {\cal M}(t_0)- q \lambda t \epsilon.<br /> $$

The right hand side of the expression is zero if $ t={{\cal M}(t_0) \over q \lambda \epsilon} $ is zero. In this case, $ {\cal M}(t) \leq 0 $, i.e. the code becomes absolutely unmaintainable. It means that any change to the code would cost infinite amount of money. And this happens in finite time! And we know exactly when will it happen!

Enforcing $ \lambda $ to be a constant has another consequence. As we know,

$$<br /> {\cal M}(t)={\cal M}(t_0) e^{-q {C[t_0,t_1] \over {\cal C}_L}},<br /> $$

but the right hand side becomes zero (actually it is decreasing linearly), and we get that

$$<br /> {\cal C}(t)=-{C_L \over q} ln {\cal M} (t).<br /> $$

When $ {\cal M} (t) $ becomes zero, the cost invested into development is infinite (as already stated!).
Let's put it into another way: Zero maintainability can be reached in finite time only if someone can invest an infinite amount of money into pure development (no code improvement) in that finite period. How luck we have that we are limited by the resources to ruin our codes entirely. So better not to touch the code at all!

We can now see the limitations of the model. The basic problem is that we wanted to maintain the change rate of the code by force. This is becoming harder and harder (means more expensive) by time, as the maintainability is decreasing. Next time, we will improve the model by allowing the change rate $ \lambda $ to depend on time. By that way we will get a model which is much more near to reality.