Sustainable Pace

of continuously delivering value to the business

Predictability

A desirable characteristic of software development is predictability... predictable delivery, predictable quality and predictable cost. We know that it is extremely difficult to have predictability of one of these, never-mind all three.

This is for many reasons, one being the ease with which the software system can be correctly and safely updated is often difficult to estimate.

Key words: False-pace; false fast-pace, technical bankruptcy.

And whilst there are many reasons why accurate estimations are troublesome, a significant contributor to this is the level of complexity of the existing software that needs to be changed.

Predictability of development ← Accuracy of estimations ← Complexity of the existing software ← Maintainability Qualities of newly written Software

Technical Debt

This is a term in software development that refers to the situation where shortcuts have been made (knowingly and conscientiously, or otherwise) that are now preventing the development team from working as fast as they otherwise could. Just as one can be saddled with financial debt that needs repaying, so to can a software team be saddled with technical debt until it is repaid.

And of course, just as debt can get unserviceable, so to can technical debt. We refer to this as a business reaching Technical Bankruptcy.

Inertia

Hopefully the diagram above is self explanatory. However, this particular diagram depicts a moment in time when months and months of investment has already been made to repay back the tech debt...that is much time and effort fixing things, refactoring and rewriting code, adding tests, changing tooling etc.

And yet, during this period of time, the team has been getting slower, they have just been reducing the rate at which they get slower. This phenomenon happens for several reasons but the three notable ones are that:

Whilst the team are spending time on improving things, they are not developing new features.
The time spent on adding new features is likely to be building on poor foundations, and thus has to be built in a non-optimal way. This means that this new code is effectively adding to the amount of code that will eventually have to be reworked.
Old habits are hard to break. Whilst some will know how to develop better code, only a proportion of these will be able to immediately start doing so. And those that don't necessarily know any better (maybe graduates, junior or mid level engineers, or even experienced but not particularly competent ones) continue to copy the style and quality of the existing code that they are wrestling with.

In short, it's very hard to predict when a noticeable return on your investment will be seen.

Prevention is better than cure.

Footnote:

GenAI coding can be used to both arrest this decline but also unintentionally accelerate it.