Introduction

Recently I’ve been reading Thinking in Systems: A Primer and playing with Emacs to do system modeling.

Reflecting on my past software development experience, I came up with the following model:

Some explanations

From a systems thinking perspective, a stock is an element that is measurable, and could have inflows and outflows. An example is capital in the investment system.

In the software development cycle, I used the Features Delivered as a stock, where feature development is the inflow that increases the delivered.

Here, I differentiate feature development from other flows like bug fixes, refactoring work, or paying tech debt. In my experience, most Agile teams adopt this type of rough categorization.

As we deliver more features, it yields more business output. The product line is expanding, and people usually want more features, so it drives up the business demands, which would push for more development. This forms a reinforcement loop (denoted by the R).

You may argue this is a bit stretched, because more output does not always yield more demands. But my experience told me output and demands are highly correlated.

If the entire system is left unchecked, a reinforcement loop will always drive itself and continuously drives up the stock.

We all know that’s impossible. I don’t think any team can push features endlessly. There got to be a limit somewhere.

That’s why I model the tech debt as a self-balancing loop: More feature delivered, it incurs more tech debt, which leads to bugs or incidents, which eventually drags the feature development rate.

At the same time, engineer happiness is affected by bugs or incidents. Fixing bugs or putting out fire all day is not fun for any one. This also has negative impact on the feature development.

Interestingly, there is a weak reinforcement loop between Engineer Happiness and Feature Delivered. Shipping new shiny features is generally a boost of emotions, the model considers that as well.

Summary

This is my exploratory work to apply systems thinking to explain the software development activities. The model attempts to define the relationships between features development velocity, engineer happiness, bugs/incidents.

Three loops are identified, two reinforcement and one self-balancing. These loops explain why feature devs are not infinite, and what may drag the development velocity down.

Of course, this is a simplified view of software development. There are lots of factors not included here, like team experience, QA, design, PM, etc. So consider this as a starting point.

Thanks for your read!o