This is the second part of a two part series on the impact of software requirements on technical debt. Part 1 defined technical debt, delved into its importance, discussed its symptoms and summarized some strategies for paying it down. Part 2 discusses the specific impact that software requirements can have on technical debt.

Brief Summary of Part 1

• Definition (Steve McConnell): “’Technical debt’ refers to delayed technical work that is incurred when technical short cuts are taken, usually in pursuit of calendar-driven software schedules.”
• Importance:
  • (Steve McConnell) “Just like financial debt, some technical debts can serve valuable business purposes. Other technical debts are simply counterproductive. The ability to take on debt safely, track their debt, manage their debt and pay down their debt varies among different organizations. Explicit decision making before taking on debt and more explicit tracking of debt are advised.”
  • (Jim Highsmith) “Unfortunately, by the time many organizations are paying attention, all the solutions are bad ones: 1) do nothing and it gets worse, 2) re-place/re-write the software (expensive, high risk, doesn’t address the root cause problem), or 3) systematically invest in incremental improvement.”
• Symptoms (Ryan Shriver):
  • “Poor Customer Responsiveness
  • Long Delivery Times
  • Late Deliveries
  • Lots of Defects
  • Rising Development Costs
  • Frustrated and Poor Performing Teams”
• Repayment Strategies (Ryan Shriver)
  • “Poor coding and testing practices
  • Poor system design
  • Poor communication and collaboration
  • Lack of standard development process
  • Poor requirements with no common definition of “done”
  • Lots of manual effort for a release
  • Lack of proactive investment in paying down debt”

Using Software Requirements Wisely to Avoid Increasing Technical Debt

Poorly done requirements have a magnifying effect on downstream activities. Per Barry Boehm, an error created early in the project, for example during requirements specification, costs 50 to 1,000 times as much to correct late in the project as it does to correct (or avoid) close to the point where it was originally created. Why are errors so much more costly to correct downstream?  There are two main reasons:  project artifacts to be corrected increase over time and more people need to get involved in defect correction as the life cycle progresses.  A poor requirement or an unneeded requirement will become the ‘tip of the iceberg’ for problems later in the project. This magnifying effect is independent of the type of software lifecycle model your organization uses. Requirements that are done poorly means the features that provide the most value to the business are not done at all, are done poorly or time is spent developing features that don’t provide the most value to the business. These can all lead to an increase of technical debt with a bad ROI. Just as in your personal finances, if you are going to go into debt, you want to do it purposefully to achieve a good ROI that factors in repaying your debt.

McConnell talks about two categories of technical debt:

• Type I – incurred unintentionally: the non-strategic result of doing a poor job.
• Type II – incurred intentionally: an organization makes an intentional decision to optimize for the present rather than the future.

How Requirements Affect both Type I and Type II Technical Debt:

• Business objectives
  • Poorly done business objectives set the project up for failure and possibly the company itself. Think of all the time and resources wasted by building features or entire products that bring little to no value to the company.
  • Additionally, all of this code added to the code base creates a “fog” that obscures the “real” code every time the developers go into the code base to add something new or fix a bug. I have seen entire forests of “dead wood” in some code bases ever increasing in size over time. As people forget (or even move on to another company) tribal knowledge is lost and the team can inadvertently spend time working on “dead wood” – modifying it, fixing it, extending it. Meanwhile technical debt continues to grow and the code base becomes “fragile” – fixing one bug creates 3 new bugs.
  • A company can contractually inherit technical debt when purchasing a component to integrate into its own product or on a larger scale when acquiring another company. The acquired component or product may contain large amounts of technical debt. Smart companies have well-crafted business objectives and the derived requirements for component purchases and software acquisitions. Really smart companies include assessment of technical debt as part of their acquisition evaluation requirements.
• Clear, Unambiguous Requirements
  • Ambiguous or missing requirements create the same havoc as poorly done business objectives. One bad requirement out of thousands on a large project is usually not as damaging as a one bad business objective, but the impact of many bad requirements can do as much damage. The same bad outcomes can occur: wasted time on the immediate project and wasted time and money through increased technical debt – growing “dead wood” one bad requirement at a time.
  • One dangerous side effect of a poor requirement is that it is difficult to know what “done” actually means. This impacts development, testing, project management and eventually all of the stakeholders.
• Prioritization of Requirements by Business Value
  • It is imperative to develop and release the most important features whether for the entire release or for a specific sprint or phase.  Prioritization of requirements needs to done according to business value. Working on lower value features first can indirectly affect technical debt when the team realizes that they need to switch effort to focus on a higher priority feature and increased time constraints may force them to take short cuts on both features that will need to be addressed later.
  • An ineffective or missing Change Management process can increase technical debt by allowing work to proceed on feature additions or changes that are not properly evaluated against the business objectives.

Using Good Requirements Processes to Avoid both Type I and Type II Technical Debt:

Good requirements processes using the following techniques can help avoid increasing bad technical debt. These are linked to previous blogs I have done on these areas.

• Listen to your customer’s needs
• Use models
• Don’t use “weasel” words
• Prioritize requirements
• Baseline and change control requirements
• Perform requirements traceability

Bad or missing requirements have a magnifying effect on downstream project activities and can greatly increase technical debt that lives on and continues to compound interest long after the project has finished. While other strategies, especially related to implementation activities, can help pay down technical debt, doing better requirements can help avoid or reduce increasing bad technical debt from the start. Remember the old Mr. Goodwrench commercials? “You can pay me now or you can pay me (much more) later.”