SPLASH Workshop - Technical Debt
October 20, 2014
Portland Oregon

Technical Debt is the cost of the work you need to do because you were in a hurry -- some parts of the design and code were not clean.


Some discussion of ideas and experiences from workshop participants:





Some questions:


Some metrics about software quality:

Testing (or at least the process around retesting code after making code changes) creates an issue for making small changes:

How can we get people to pay attention to things that could be serious?

There is less and less interest in paying the cost of building systems with high reliability

Suppose that one of my underlying development assumptions has changed - is this technical debt?


List of potential questions to explore


Some strategies

In thinking about legacy code and technical debt, we need to consider both the "engineer view" and the "decision-maker view"


There are downstream consequences of fixing technical debt

Agile and its interactions with Technical Debt


An observation about Agile:

XP technical practices

Certification...

Is Technical Debt another word for quality?


Final question list for the main discussion

  1. Mitigation of Technical Debt and strategies (6 votes)
  2. Managing Technical Debt; is it inevitable; does it matter; what are the costs (5 votes)
  3. How to make Technical Debt visible; how to measure (4 votes)
  4. Agile and Technical Debt (3 votes)
  5. How and what to teach the next generation about Technical Debt (2 votes)
  6. Can we use the Technical Debt metaphor for other choices? (acquiring other companies, decisions about retiring software products) (1 vote)
  7. Is Technical Debt about the infrastructure / substrate? it might not be so much about the "apps" (which can be throw-away software) (0 votes)

1. Mitigation of Technical Debt

Can we come up with a cost of doing a better solution? Will this help us make better choices?

What doesn't work:

Better: working together - figure out what we can ship this year (build an architecture and design to support it)


It is useful to share information about the cost of the shortcuts

Question: Is "forking" guaranteed to create Technical Debt?

Another good strategy: Keep a list (Technical Debt backlog)

(The idea of "identifying individual Technical Debt issues" is consistent with Philippe Kruchten's "Four Color Backlog". The four colors are:

This is a useful way to make sure that technical debt reduction activities aren't completely lost in the list of new customer-facing features.)

More about "keep a list of Technical Debt issues":

What is in the Technical Debt list?

Does the skill set and experience of your software team have an impact on the level of Technical Debt?


More on mitigation strategies

Include scenario-based modles and issue tracking

Another good mitigation technique: "engage testers"

Question: are testers part of your team, or are they a separate organization?

We need continuous test

Follow good encapsulation principles; write clean code


2. Managing Technical Debt

One criticism by managers who don't believe in Technical Debt:

One management strategy:

A management strategy that creates problems:


When something blows up

Question: Is it professional to "make technical debt worse" to make it visible?

Risk management process can help:


Some good books on "teaching design thinking":


3. How to make Technical Debt visible

How to "identify" technical debt:

Static code analysis tools find some technical debt problems, especially in a large legacy code base.


Watch out for local rewards...

Peer-to-peer collaboration works better than central command and control (in many cases)

Of course, the management style of the organization is reflected in the architecture of the solution (Conway's Law)

Do you have people who can think about larger issues and share things across the teams?


Changing platforms -- this exposes many code quality issues

Metric: How much is your build/test/deploy cycle slowed by Technical Debt?

Invest in early unit test


More on making technical debt visible

Keep a list of Technical Debt items

Look at future feature -- compute the development savings if you invest in fixing some technical debt first...

Watch out -- you might not need to fix the technical debt


There are good things and bad things about the Sonar approach to measuring technical debt

Sonar counts several things:

Why is this not so good as a technical debt measurement?

In the code inspection process, you don't always have to see all of the code to make a partial assessment of problems:

More things to look at in code inspections:


If you do a performance test - can you find Technical Debt in dynamic resource consumption?

Make sure you have performance tests and load tests in place

In the analysis of test results, be aware of the root cause of the problems.

Question: Who do you make Technical Debt visible to?

There is a lot of "underinvestment" in development

We just "bolt on" changes to an existing code base, creating a "house of cards" (from a Guardian article about a bank software crisis)


5. What do we teach the next generation?

it is a process of "educating"

people tend to think local not global

we need to convince students that TD is important

and convince faculty that it is a topic that needs to be in the curriculum

it is a challenge to teach the right thing -- not enough academic awareness

need projects to get experience


One teaching experience: doing a group project to build a small system to fill out a tax form

Problem: most problems have a scope that is too small (students would prefer to work on the problem on their own, not as a team)

but it is better experience for them to work in a 5-6 person team

One idea -- instead of a big multi-week project, use something like the old OOPSLA Design Fest

Another idea -- Alistair Cockburn's coffee machine exercise

Hackathons -- good for teamwork

Working with legacy code


What happens when you "learn the right way in school", but when you go to the work works, they aren't doing it right?

There are things that individual developers can "do on their own" to deal with technical debt: