Drowning in Debt
In Software Development, much like in Finance, having too much debt can be a real burden. In developing software there are trade-offs and reprioritization so that you can deliver the most business value in the shortest amount of time. When a feature, fix, or enhancement is deemed necessary but not urgent, and is thus delayed, there is a future liability created. Likewise when functionality is implemented in a way that will have to be refactored in the future an expense is incurred. This expense is called technical debt and refers to the eventual, additional development that has to be done at some point in the future to finish a particular piece of software.
It is easy to draw parallels between technical debt and financial debt. Most people understand the concept once explained even though the actual technical debt can be difficult to identify since shareholders may have different opinions as to what is debt versus an enhancement. The theory of technical debt is a great convention to communicate to laypeople (non-techies) that there are things that have to be done in the future to “clean up” existing software and make it more robust.
So technical debt is understood as something that has to be paid, and it is something that is used on purpose to help deliver, some say finance, a high value product. Yet what isn’t discussed as often is the fact that just as there is interest paid on financial debt, there is interest paid on technical debt. This issue is germane to fully understanding technical debt.
Consider that not all debt is accepted at the same interest rate, nor, depending on the age, does all debt have the same accrued interest. That is a basic financial tenet but this is frequently overlooked when dealing with technical debt. The point here is to promote the concept of “accrued interest” when reviewing your technical debt.
Calculating the accrued interest can be challenging yet thought-provoking and it often requires a certain level of sophistication to correctly derive an agreed upon value. We can continue to use financial principles to illustrate how interest is calculated by using the following formula:
I = P * r * t
This is to say that Interest is equal to Principle times Interest Rate, times Time.The most important realization is that accrued interest increases exponentially as time passes.
The formula presents a framework for assigning a value to debt items and incorporates time as a vital (albeit often overlooked) dimension when calculating which items have the highest debt.
So in summary, it is important to dive beyond cursory knowledge of the technical debt concept and move to a more comprehensive understanding by incorporating and valuing debt over time. Items that linger “on the books” can become very costly and should be addressed. Furthermore, it is vital to recognize how much debt a company should carry and responsibly manage the burden.
Michael Eisworth joined the development organization last year to help provide reporting solutions. He has been developing information management systems since the late 80’s.
Posted In: Tips,
- Include Requirements & Contribution Sub Types
- User Case Story from Hope Community Church
- Group Search Categories and More
- Account Creation
- Single Sign On Functionality Exposed
- API Communication Value Changes
- API Enhancement: Create and Edit Groups!
- API Enhancement: Requirements Exposed
- Resource Versioning
- Enter Visitor Data via Your Church Website
- Fellowship One & Planning Center Online
- API Libraries and Sample Code
- Building a custom login for your church website using the API
- Roll Foward!
- The Agile Triangle
- Conversation Paralysis
- Picture this, image updates & creates through the REST API
- A REST API double shot : Groups and Events realms
- Increasing Software Delivery by 500%
- Quick people API realm update
- Introducing the new REST API giving realm
- Raising the bar…
- Building a Deployment Pipeline
- The World of Dev Craft
- Running Tests in Parallel with Selenium
- Abstracting Your Code to Remove Duplication
- Documentation in an Agile Environment
- Drowning in Debt
- Intro to Ruby on Rails
- API Strategy & Roadmap
- Staging/Sandbox Environment is Back up!
- Downtime in Sandbox/Staging Environment
- Android & OAuth
- F1 API Static Library with Objective-c
- Programming in F#
- NoSQL: HuMONGOus Benefits (Part 2)
- Our Scrum Team Structure
- SaaS & BI - The History & Future
- Getting Started with Android
- NoSQL: Leaving Schema Behind (Part 1)
- Your Feedback…and a $25 Gift Card!
- A Scrum Ceremony? Is this a wedding or something?
- Variables in PHP
- Data Exchange API Fixes
- F1 Check-in on the iPad
- Be the first to get the news & tips!
- An Introduction to PHP
- Working with Pop Up Windows in Selenium
- List Comprehension
- Source Control: A Time Machine For Your Source Code
- Developer Conference…Lower Price, Same Great Content!
- The Quality Assurance Team
- How does Fellowship Technologies manage complex projects?
- Developer Conference coming in May!
- Sandbox Refresh Complete
- Sandbox Refresh This Week
- Updates coming to the REST API
- Sandbox Environment Down Time
- F1Touch :: Fellowship One On The Go
- Under the Hood
- Sandbox Refresh Complete
- Sandbox Refresh Tomorrow (Oct. 2nd)
- Fellowship One Developer Forums
- Ten Commandments of API Consumption
- REST API Enhancements / Fixes deployed to Sandbox and Production 09.09.09
- Data Exchange URL cut-over complete
- Important Data Exchange URL changes
- Ron Nom Nom
- How to get started using the REST API