DZone
Thanks for visiting DZone today,
Edit Profile
  • Manage Email Subscriptions
  • How to Post to DZone
  • Article Submission Guidelines
Sign Out View Profile
  • Post an Article
  • Manage My Drafts
Over 2 million developers have joined DZone.
Log In / Join
Refcards Trend Reports Events Over 2 million developers have joined DZone. Join Today! Thanks for visiting DZone today,
Edit Profile Manage Email Subscriptions Moderation Admin Console How to Post to DZone Article Submission Guidelines
View Profile
Sign Out
Refcards
Trend Reports
Events
Zones
Culture and Methodologies Agile Career Development Methodologies Team Management
Data Engineering AI/ML Big Data Data Databases IoT
Software Design and Architecture Cloud Architecture Containers Integration Microservices Performance Security
Coding Frameworks Java JavaScript Languages Tools
Testing, Deployment, and Maintenance Deployment DevOps and CI/CD Maintenance Monitoring and Observability Testing, Tools, and Frameworks
Culture and Methodologies
Agile Career Development Methodologies Team Management
Data Engineering
AI/ML Big Data Data Databases IoT
Software Design and Architecture
Cloud Architecture Containers Integration Microservices Performance Security
Coding
Frameworks Java JavaScript Languages Tools
Testing, Deployment, and Maintenance
Deployment DevOps and CI/CD Maintenance Monitoring and Observability Testing, Tools, and Frameworks
What's in store for DevOps in 2023? Hear from the experts in our "DZone 2023 Preview: DevOps Edition" on Fri, Jan 27!
Save your seat
  1. DZone
  2. Testing, Deployment, and Maintenance
  3. Maintenance
  4. Tech Debt- Balance Sheets

Tech Debt- Balance Sheets

Here we take a look at the concept of 'balance sheets' when it comes to technical debt. Are they useful? And what the heck are they in this context?

Paul Hammant user avatar by
Paul Hammant
·
Apr. 10, 17 · Opinion
Like (4)
Save
Tweet
Share
6.71K Views

Join the DZone community and get the full member experience.

Join For Free

The grandpappy of modern programming, Ward Cunningham, coined “tech debt” for situations where the codebase should be refactored or improved before moving on to new work. As a metaphor, it is a little too simple though. A few have thought of more catchy metaphors over the years. One was Steve Freeman with "Unhedged Call Option." He was citing Chris Matts and there was quite a conversation on his blog afterward. A week ago, Gregory Brown said on Twitter: "For this to be technical debt there would have needed to be a benefit somewhere else. Otherwise it's just technical damage."

Hmm, that is interesting. It feels like debt is something that can be paid off anytime, yet technical damage builds up, and compounds in very visual ways (like a rusty chain on a bicycle), perhaps leading to a calamitous failure. Damage hints at the inevitability of dilapidation following neglect. Or it hints at the accretion of layers of bad stuff - like cholesterol in hardened arteries.

Before we go too far, here is Ward on video in 2009 on the debt topic:


Anyway, I think debt is the right metaphor after all, and with DevOps as an encompassing practice, we are able to say that technical debt can occur anywhere - databases, environments, firewall configurations, silicon, shared services (between environments), etc. Oh, and the missing scriptability and elasticity of those, specifically.

But there are caveats, randomness, and a balance sheet of multiple debts, I think:

You Don’t Always Know You’re in Debt

Specifically, of the hundreds of little loans you’ve taken out in a codebase, your skill/experience/tooling may mean that you can’t recognize many of those little loans.

If You Do, Think You’re Taking out Low-Interest Loans Exclusively

When debt is via regular loans, it should be structured and predictable. In a period of time where interest rates are low, you expect structured, predictable, low-interest loans. You understand that interest has a compounding effect, but it should be manageable in a low-interest situation.

Some are not, though, and you are overconfident to expect that all should be. Again, skill, experience, tooling, and possibly chance may prevent you from knowing which debt situations will quickly and silently transform into loan-shark style ones that are hugely problematic. You may have thought you had two years to pay off that loan at low interest rates because that is what the market is doing presently, but not so in some cases. Even when you thought the terms were clear up front, some of those loans have been secretly resold to the local break-your-leg mob and had those terms changed. Now repayment is a priority, and at high-interest rates, is changing your focus from throughput of value to stressing about the loan.

Debt Isn’t in Your Name, It Is in Your Employer’s (Most Likely)

Broken legs? Not really: you can always quit that job and escape this debt completely. The Inc/Llc/Ltd/Plc is where the debt stops. That loan shark is going to break someone else’s legs - a whole company (companies are people too!). The stock market could savage their valuation but not yours. You just move on to a new job - you’re indemnified.

Really, though, you should have no authority to silently accumulate debt as you are not the CFO.

Given your ability to escape the debt and the uncommunicated nature of the loans and their interest rates, you have robbed the CFO of part of their job - budgeting software delivery and the multi-year costs of ongoing ownership. The CFO had the authority to put the company in debt (for the board), not you as software/IT  professional  careerist. Of course, there were plenty of others encouraging the repeated debt-embracing habits, including non-technologists in key roles, so it is not all on you.

Finance thinking people never ask for a balance sheet from software writing groups that would show such debt, so value calculations are always optimistic. They have an impact though. For example, some part of Travelocity’s demise was because it hadn’t paid off its technical debt. It was ultimately sold for $280M but its peak valuation was billions.

All Is Not Lost

With IDEs that support refactoring, you can face something that could be high-interest or risky debt, and eliminate it in the same commit or immediately after- at least, in the same cycle as the creation of the apparent value that was asked for in the story/task. Indeed, IDEs (like Intellij) can be so good at this that you can start to look at large changes as not risky, and not debt creating. You end up with refactoring as an ordinary team activity and a codebase that is “most stable." Of course, none of the finance or business people care today, as we’re not communicating a debt balance sheet weekly, but that could change, too.

Craftsmanship

Steve and Chris were interviewed for InfoQ magazine in 2014. They talk around the relevance of the ‘Unhedged Call Option’ piece. They finish the discussion with a thought about the software craftsmanship movement- a solid thought. It seems closer to the rust metaphor again. Prevention of rusting, that is. Or prevention of rot with varnish, etc.

tech debt

Published at DZone with permission of Paul Hammant, DZone MVB. See the original article here.

Opinions expressed by DZone contributors are their own.

Popular on DZone

  • Implementing Infinite Scroll in jOOQ
  • 2023 Software Testing Trends: A Look Ahead at the Industry's Future
  • Beginners’ Guide to Run a Linux Server Securely
  • Memory Debugging: A Deep Level of Insight

Comments

Partner Resources

X

ABOUT US

  • About DZone
  • Send feedback
  • Careers
  • Sitemap

ADVERTISE

  • Advertise with DZone

CONTRIBUTE ON DZONE

  • Article Submission Guidelines
  • Become a Contributor
  • Visit the Writers' Zone

LEGAL

  • Terms of Service
  • Privacy Policy

CONTACT US

  • 600 Park Offices Drive
  • Suite 300
  • Durham, NC 27709
  • support@dzone.com
  • +1 (919) 678-0300

Let's be friends: