BOOK CLUB: Reading 'The Book of TameFlow'

Reply to this post with comments, corrections, reflections, questions about The Book of TameFlow, Theory of Constraints Applied to Knowledge-Work Management!


Location 602 when reading the book in my Kindle reader.

Patterns. A very interesting concept. There is even a definition of so-called Alexandrian Patterns.

Often I hear the term Patterns - as something positive - a solution to a problem in a context. I also often hear the term Anti-Patterns - which is then some action that has a negative effect - which may not be clear (maybe not consciously observed).

In many organizations information technology is an important means to an end of trying to solve problems. Often there are deadlines for internal or external reasons considering an organization a system part of a larger system (society).

Now at every moment in time decisions are being made by individual human beings and groups of human beings.

Some decisions are made in order to meet an important - and urgent deadline.

Now here is a tension.

If a decision is made now in the present moment in time - is it then clear what desired outcomes / effects are (if the decisions and actions are seen as the cause)?

I am trying out a proto-pattern with the intent of making decisions where IT is at play clear related to the concept of technical debt.

So if we knowingly make a short term decision that we believe will incur technical debt - then we at the same moment in time commit to resolving the technical debt “right after” - if working iterative and incrementally. This is probably not 'build-in quality" - but…

I am curious what you think about this proto-pattern?

Would you see this as a pattern (positive) or anti-pattern (negative) and why?


Have you checked the Appendix about Alexandrian Patterns?

1 Like

Technical debt has become the object of my latest research, so I kinda feel compelled to mash together some ramblings here.

First of all, what do you call “Technical Debt”? Can you define it? I’ve come across dozens of papers with different models for tech debt (see some at the bottom of my response). They are all different.

Now, let’s assume some genius came up with an ontology of Software Development that could define what technical debt is. Then I would feel confident in giving an opinion, never an answer, to the question you are posing here.

In the absence of such ontology. I’m going to reach to my flawed mental model for technical debt; which I presume could be different from yours, to pose another question. If we were going to understand tech debt as the sloppy code that makes team going slower overtime (because they are “busy paying the interest rate” on that debt); is it all tech debt worth paying back?

Martin Fowler said: I only trigger an interest payment when I have to work with that part of the software. If that’s true, why would we commit to addressing something if we knew we were not going to revisit it?

Finally, is it the proto-pattern you are proposing positive or negative? Based on my reasoning above, my answer is, it depends.

Some sources (you would have to google these!):
Value-Based Technical Debt Model and Its Application
A portfolio approach to technical debt management
The economics of technical debt
The financial aspect of managing technical debt
Measuring architectural debt
Managing Software Debt
Software Design X-Rays


I just posted a good link on LinkedIn.
The author’s opinion was what while, in theory, technical debt could be paid back, in practice it almost never was. He said he had seen technical debt that was so long lived it passed into the next version of the product.
So it’s probably better to follow the advice about expediting. Don’t do it. There are all kinds of justifications and excuses for it…but in the end your system is more productive if you don’t do it.


Thank you for your answer.

Firstly I agree that there are a plethora of definitions of technical debt - which is the case for many other concepts.

The key word for me here is more the “debt” part than the “technical” part.

A debt is something owed that must be paid back.

So “technical” here refers to information technology - which we could divide into hardware and software. If we focus on the software part you might deliberately choose to develop and deliver software fast knowing that you choose to fix something later. If you never pay the debt back over time the debt may accumulate to such an extent that you are not able to pay it back. Metaphorically speaking you go bankrupt.

So allowing this to happen even once could be considered an anti-pattern - unless you pay it back right after.

I could also argue that not building quality in is suboptimal - so a pattern could be to build quality in evaporating the idea of technical debt.

So maybe we should just take a balanced approach.

The challenge is a bit like the parable of the boiling frog (please do not try this). Some say that if you put a frog in a pot with cold water, then put it on the stove and slowly heat the water - the frog will not notice the gradually temperature increase and ultimately be boiled to death. Maybe that is what is happening with unconsciously allowing technical debt to build up?

Here an interesting video describing technical debt:

1 Like

An example is the IT application JIRA where all work items are called issues which confuse a lot of people. Apparently this is hard coded and cannot be changed (easily) :slight_smile:

Thank. You I am rereading it now.

I think that e.g. your example comparing a mudhut and a sky scraper very well explains how applying one pattern will change the context and then another pattern might be utilized.

Maybe I will find an example of such a thing happening in my own context that I can share.

1 Like

Update 2021-05-29: I just published a new revision, with lots of cleanup and renumbering of all parts and chapters, including cross references.

If you get this revision, please do me a favor: when you come across a cross-reference, please double check that it properly matches the destination.


1 Like

Using the concept of a pattern I intent to try to describe a context, a problem and the solution I will try out.

Starting (for further refinement)…

Proto-Pattern X:

A new process is being developed which consists of customers and people and is supported by IT systems with data inputs and data outputs.

There is no defined process and the data input and output is unclear.

Visualize the data input the people and process steps and the data output in collaboration with those accountable for the individual process steps by defining / traversing at a high level of abstraction and then reiterating at a continuously more specific level of detail.

1 Like

A Pattern in and by itself is of little use. There is the risk of turning it into a common acceptation “pattern,” a template, a cookie cutter. That is not what Alexandrian Patterns are about.

You must always put a Pattern - any Pattern - in relation to the other Patterns of the Pattern Language you are building to describe your domain.

Use the Pattern Form described in appendix of the book. This one:

  • Pattern Number::
  • Pattern Name::
  • Confidence::
  • Diagram::
  • Context/Forces::
  • Problems::
  • Narrative::
  • Solution::
  • Structural Diagram::
  • Resulting Context::
  • Related Patterns::
  • References::

While you can start with the trio context-problem-solution, what becomes more important is the Confidence level, the description of the Forces that are interacting in that Context and what are the other, Related Patterns.

Also, as the Pattern is refined, you have to work on the Narrative because we are building a linguistic construct.

But it is good that you want to get started with Patterns! I encourage you to continue and give us all your feedback or discoveries here.

1 Like

The concept of Enlightened Self-interest might not be covered in the book while considered a pattern.

Will this pattern make sense if executive management does not understand and agree to the mental models made explicit in TameFlow?

1 Like

Hi, Steve. I took advantage of your special offer and purchased a copy of the book. Thank you!

I haven’t gotten far into it yet, but I noticed a typo on p. 1. The word “Knoweldege” should be “Knowledge.”


1 Like

Hi @dpaulsims and welcome here!

Thanks. Fixed!

Typically this (as many others) is not a Pattern that you go about explaining and expect management (or anyone else) to say “Aha! I will work on my ESI!”.

It is a Pattern that you will observe at work, and is a confirmation that the Mental Models are moving the hearts and minds in the right direction.

Does it make sense?


Hmmmm. Does it make sense? Maybe it does. So the pattern of enlightened self-interest is something that might be observed as a result of shared mental models? As an example: The sooner I start on something, I will finish it (if I am only myself and task is simple as turning in the light) while the sooner I start on something if we are more that need to collaborate is maybe not correct the more we are that need to collaborate - hence it is okay that some are not busy? If both e.g. those giving overall direction (management) and those executing the work shares a mental model - then the enlightened self-interest of both groups mentioned here might be more freedom to do whatever you want - as long as you are not the one keeping execution of work back?

Part of describing a pattern can be a “Structural Diagram. If applicable, a diagrammatic representation of the solution.”

I am curious if anyone can share an example of visualization of a solution as one of the attributes in an Alexandrian Pattern?

1 Like

On the topic of #patterns @kentyer made me reflect also on #mental-models

Do you ever find yourself in a context where you need to make a decision - maybe as a group of people? Maybe you want to figure out whether you should move forward so you summon you collective brain and find some way to make a decision.

How do you prevent the cognitive bias of an echo chamber or group think?

Do you ask someone maybe outside the group to act as the Devil’s Advocate or The Tenth Man?

Kahneman talks about having a specific “observer” role…but he warns that it can be very difficult to play and that over time the group might not tolerate it. After reading “noise”, we also need to factor in the idea that it is not just “bias” that distorts a group’s decisions…“noise” is probably a bigger and more significant factor.