Strategizing Your Technical Debt: The Good, The Bad, and The Necessary

by

One of the great things about the technical debt metaphor is that it expanded the conversation on software entropy and complexity to include the business that software is used by and maintained for. The simplest understanding of technical debt is that it is the result of a lack of technical rigor - whether it be voluntary or involuntary. Regardless of how it was incurred, technical debt has to be managed at one time or another. This should be done from a strategic standpoint with support of the backlog and help of the client.

The creation of debt itself, contrary to popular belief, is not always due to a lack of skill or discipline. At it's best, it is created to meet a business need that otherwise could not be met. So when starting the discussion of technical debt you have to aware of the different levels of it, and the costs associated to each level. Martin Fowler, for example, states that missing a payment on a credit card will end up costing you a lot more than missing a payment on a long term mortgage plan. By using personal debt as an analogy to technical debt, it helps to identify debt in various domains.

Core domains of your system should be in line with agile development practices (they should be testable, have low coupling and high cohesion) so that you can enact change quickly and easily. However, utility domains, similar to the long term mortgage example, can handle more debt as they are less critical to your application.

Keeping a technical debt backlog can be a great way to track your debt, but keeping your technical debt in the product backlog makes more sense. Firstly, these debts belong to the product and will therefore affect its total cost of ownership. Secondly, it is easier and less confusing to put everything regarding the product in the same place. This simplifies tracking everything related to the business, product, and IT. Once the technical debt has been listed in the product backlog, any decision regarding it should be business oriented: i.e. what are the costs, risks, and urgency associated with leaving the debt as it stands.

This is particularly the case with start ups where paying debt right away isn't the most pressing issue on the schedule - gaining a customer base and building your product/market fit. Debt is also usually ignore in an end-of-life system. These two scenario's of ignored debt are driven by business needs not technical ones.

However, when you're not in the start-up or obsolete phase of your product, short term objectives can't be driving your strategy. Just as when you buy a car, you don't simply expect that the costs associated to it will be the sticker price. Maintenance is necessary in order to ensure you get all that you need out of it. This is the same when developing software.

To read the full post visit here.

Filed in: Technical Debt
Get the Pulse Newsletter  Sign up for the latest Software Intelligence news Subscribe Now <>
Open source is part of almost every software capability we use today. At the  very least libraries, frameworks or databases that get used in mission critical  IT systems. In some cases entire systems being build on top of open source  foundations. Since we have been benchmarking IT software for years, we thought  we would set our sights on some of the most commonly used open source software  (OSS) projects. Software Intelligence Report <> Papers
In our 29-criteria evaluation of the static application security testing (SAST)  market, we identified the 10 most significant vendors — CAST, CA Veracode,  Checkmarx, IBM, Micro Focus, Parasoft, Rogue Wave Software, SiteLock,  SonarSource, and Synopsys — and researched, analyzed, and scored them. This  report shows how each measures up and helps security professionals make the  right choice. Forrester Wave: Static Application Security Testing, Q4 2017  Analyst Paper
This study by CAST reveals potential reasons for poor software quality that  puts businesses at risk, including clashes with management and little  understanding of system architecture. What Motivates Today’s Top Performing  Developers Survey
Load more reviews
Thank you for the review! Your review must be approved first
Rating
New code

You've already submitted a review for this item

|