Feature Requests Vs. Technical Debt: What Is The Right Balance?

We recently hosted a Tech Debate on the subject of technical debt and its’ impact in software development with two subject matter experts, Mark Friedgan, CEO of Credit Ninja and Mike Sandler, CIO at Eligo Energy LLC. The debate focused on striking the right balance between feature development and the handling of technical debt, the challenges it presents and how it can be measured. Missed the debate? No worries! Download our White Paper and learn how to properly balance technical debt.

What You Will Learn

1. What is Technical Debt?
2. How and why technical debt occurs
3. How to quantify and measure this type of technical debt
4. How it impacts both the technology and business side of your organization
5. Best practices for managing Technical Debt

Addressing Key Challenges

When it comes to technology debt, it’s vital to understand that the debts found in your software code represent more than just lost hard costs. There’s also the “softer” costs that come when the debt affects your team’s ability to get things done. Whether these “things” are bringing new services to market or properly engaging the customer, your debt often foretells dire consequences that slow or stop productive everyday work. Addressing debt is challenging, and requires a committed approach. Left unchecked, technology debt becomes a cycle, where poor code leads to increased time and costs, decreased agility, less revenue, and therefore less available money for better development. Thankfully, it’s possible for companies to break this cycle by proactively meeting the core challenges head on.

Managing tech debt is a big undertaking, one that requires IT and other departments to work hand-in-hand. Here are several steps for minimizingdebt and keeping software running at an optimal pace that encourages (instead of impedes) your growth.

Identify and Quantify the Debt

This will sound cliché, but the first step is “admitting you have a problem.” Meaning, it’s crucial to be able to see and recognize the debt in your programs and organization. Review the current technology to find areas where it’s possible to quantify the costs that come with poor application quality. You need to be able to express these costs so that the rest of the business units can visualize the impact of the debt across the organization, especially as it relates to the end customer and revenue. The costs of the debt are amplified when the debt-laden technology causes outages or data becomes unusable or inaccessible. Quantifying costs will require a deeper look into various code quality metrics, usability figures, and data on the time required to fix problems as well as add new features.