Tester's Digest

TESTER’S DIGEST

ISSUE #7 - Mar 19, 2017

This issue is cobbled together in haste due to a new baby arriving ahead of schedule. Please excuse possible newsletter delays over the next few weeks. Our topic this week is technical debt, as a few good posts caught my eye.

Topic: Technical Debt

Thoughts on technical debt from a developer’s perspective. Interestingly, the acceptability of taking on tech debt is not left up to the developer, but instead framed as a conscious business decision:

The “iron triangle” model of looking at technical debt says that any project faces tradeoffs between schedule, cost and scope (that’s the triangle), with the hidden 4th being quality; imagine it being the area of the triangle. If you bend the sides inwards by taking shortcuts, you’re squeezing the quality out. Has specific recommendations for managing technical debt if JIRA is your tool - wish it went into more detail on that.

Identifying and quantifying architectural debt, from a 2016 ICSE paper. The technique looks at cooccurrence of code changes in file sets over time to identify changes that stem from architectural debt. Analysis of several Apache projects suggests that this type of debt accounts for 85% of the total project maintenance effort!

Managing “process debt” (bugs, testcases, documentation) as a variety of technical debt. I like the concept of auto-closing bugs that have been dormant with no updates for >6 months with a note “Will Not Fix - Over Six Months Old”.

Lessons from scaling Twitter - broader than technical debt alone, of course, but does touch on the topic. “There is no such a thing as a temporary change or workaround: In most cases, workarounds are tech debt”:

On the intersection of product quality (less is more, when it comes to features) and classic quality (absence of bugs, maintainability), and an angle on technical debt (if you take it on, you have to pay it back), from Spotify:

Off-Topic

You know how you should always test for short and long input strings, right? Not everyone does; so a single-character first or last name, or 67 middle names, easily breaks many governmental record keeping systems.

If you received this email directly then you’re already signed up, thanks! Else
if this newsletter issue was forwarded to you and you’d like to get one weekly,
then you can subscribe at http://testersdigest.mehras.net