Many articles and posts online show how regular, small, incremental change result in much larger gains over time. This article applies compound interest calucaltions to show that a 1% daily increase provides a 37.8-times improvement/growth/whatever over the year. The power of compound interest! Frustrating at first, but the gains grow each day, at the end very pleasing.
Software engineers make decisions daily about the design and implementation of the solution being worked on: functionality, code structure, data validation, flow, error handling, security, performance, reliability, external dependencies, configurability, and more. Expected functionality and time-to-market often prioritizes what is included and what is deferred/ignored: certain failures/errors are accepted, edge cases require manual implementation, etc. It’s feature/implementation/tech debt that likely needs future remediation.
The question is whether compound interest calculations can be applied to software development as well. It appears it can, though some may not like the conclusions.
Incremental Software Development
Without diving deep into different software development models or methodologies, accept that software engineers are often encouraged to develop and release small incremental chunks of a solution rather than waiting until a single big-bang/all-or-nothing complete solution is available. There are different ways to achieve this; more importantly each new subsequent chunk builds upon previously-released chunks, eventually – hopefully, if everything goes right – delivering a “Functioning Solution.” Fast follow-on work is often required to complete or strengthen the solution, but the goal is to deliver a working solution faster than you might otherwise, to receive immediate feedback from users, and adjust if necessary the functionality or behavior.
Based on the initial posting (above). assume that every day the software engineers increase and improve your organization’s software solutions by 1%. Also assume that there are 230 working days/48 working weeks per year (accounting for PTO, holidays, training, illnesses, etc.).
(1.01)^230 = 9.861
Therefore in one business year there has has been a nine-time increase in product functionality. [Perhaps 1% is too high, but for demonstrative reasons it suffices. Organizations measure productivity in different ways, so whether 1% or 0.5%, it’s fairly subjective.]
Incremental Software Debt
So how about where decisions result in less-than-optimal solutions, such as cut-and-pasted code that requires dual maintenance or solutions where anything larger than average is non-performant. This is most often referred to tech debt, and often is, but may also be other forms such as feature debt, implementation debt, or any problems that may impact engineering’s ability to deliver at some later time.
For debt. assume that across the organization implementation design and implementation decisions are made that add 0.05% debt per day, i.e., debt is assumed to be bad.
(1.005)^230 = 3.149
Because some debt is organically or explicitly remediated throughout the year, it’s unlikely that year-over-year the debt is three times larger; however, unless you work for a forward-thinking organization and has scheduled time to address technical issues – bug bashes, engineering weeks, back-offs, whatever – the debt likely grows faster than it is addressed, and quietly become the lurking monster in the corner, ready to pounce.
Final Thoughts
It’s tough to argue with straight-ahead development and ignoring the consequences if the benefits are three times the cost. Unfortunately, it’s not that simple: eventually the cost (debt) grows to a level where it does impact on-going development, where debt must be resolved or addressed before moving forward with whatever is on the kaban board.
Over time, the percentages move closer together and, eventually, may flip so that debt is accumulated faster than features can be delivered. Leadership gets concerned when the flip is severe enough that time-to-delivery is impacted, potentially to the point where retaining customers becomes an issue. In extreme cases, the debt is so overwhelming that it almost appears prudent to start a re-implementation effort …. which starts the cycle all over again.
Ideally the debt is given attention to prevent it from getting out-of-hand; unfortunately, most organizations I’ve worked with see it as evil and tries every trick to avoid actually addressing it. Usually it just delays the reckoning, though leaders are hoping that happens on someone else’s watch.
