Categories for non-functional requirements

An alternative approach than the Flow Framework.

  1. Does the activity reduce a negative effect or reinforce a positive effect?
  2. Is the result of the activity visible to the users?

Technical drag

As I have posted earlier, I use the umbrella term “technical drag” instead of the traditional “technical debt” because I find the latter lacks nuance. The term “technical drag” includes everything that slows down development. This includes four subcategories:

  • Technical ignorance. Sometimes solutions are more complicated than we have skills to implement. In these situations, we implement bad solutions because we simply don’t know they are bad.
  • Technical debt. When we have issues in production and we are losing money we may need to implement a quick and dirty solution just to stop the bleed. Immediately after the situation is resolved we go back and reimplement a proper solution. Technical debt is when bad solutions are short-lived.
  • Technical waste. When our bad solutions are not addressed and are allowed to embed themselves into our codebase, they are no longer “debt” they are “waste.” They are pollution and sabotage.
  • Static content. Bad solutions slow us down but so do working solutions, documentation, tests, and everything else that is written down. The second we write something down we need to maintain it and include it in our mental models.

Accelerator

This is the most fluid category, as it covers any activity that we expect to increase our productivity over time. Common examples include:

  • Experimenting with a new feature (unrequested)
  • Studying blog posts, books, or videos
  • Trying a new tool
  • Automating manual process
  • Increasing code quality by adding tests or error handling
  • Improving our development process
  • Sharing knowledge or experiences

Conclusion

At this point, I recommend to our customers that they tag their tickets with category and visualize these four categories using “created vs resolved charts”, and visualize the distribution in a pie chart. This way, if we prioritize technical debt too little we should see that created and resolved are running parallel, or even worse moving away from each other.

--

--

Get the Medium app

A button that says 'Download on the App Store', and if clicked it will lead you to the iOS App store
A button that says 'Get it on, Google Play', and if clicked it will lead you to the Google Play store
Christian Clausen

Christian Clausen

I live by my mentor’s words: “The key to being consistently brilliant is: hard work, every day.”