Compound Interest in Software – DZone

Many articles and posts online show how regular, small, incremental changes result in much larger gains over time. This article applies compound interest calculations 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 grew each day —  in 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 prioritize 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 to 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 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 as tech debt, and often is, but there 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 have 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 ignore 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 ongoing development, where debt must be resolved or addressed before moving forward with whatever is on the Kanban 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 try every trick to avoid actually addressing it. Usually, it just delays the reckoning, though leaders are hoping that happens on someone else’s watch.

Image Credits

• “Compound Interest Street Sign On Wall Street” by investmentzen is licensed under CC BY 2.0.
• “31345-013: Second Education Quality Improvement Project in Lao PDR” by Asian Development Bank is licensed under CC BY-NC-ND 2.0.
• “Scrabble Series Debt” by ccPixs.com is licensed under CC BY 2.0.