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

  • 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.


  • 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




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

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