How the Software Machine Works

What System Dynamics can teach us about healthy teams and happy code

Managing technology projects and teams is full of hard decisions and imperfect information.

Should you prioritize speed or quality?

Should you fix tech debt or focus on new features?

Should you build or buy?

These decisions are rarely straightforward and are never easy. A decision made in one place can have big unexpected consequences somewhere else. Navigating between alternatives is a balancing act that is hard for even the most experienced among us to pull off. But making those choices — and more importantly, communicating them — is essential.

Generally, people rely on gut, intuition, or even worse, Best Practices™️, to help them make and justify their decisions. But those approaches are all half measures at best. They try to answer What We Should Do but they totally neglect Why Should We Do It.

Talking about alternativesis easy — everyone can stumble through a debate on meeting cadences and test coverage. Talking about the reasoning behind the decisions and the consequences of them (the Why Should We Do It)

Referencing Best Practices™️ is a cheap shortcut.

But taking that “because I told you so” approach shuts out the people who need to understand the decisions the most. It can make decisions feel arbitrary and the teams who make them seem uncooperative and adversarial.

But some companies don’t tolerate “because I told you so” cop-outs. Instead, they push their teams to understand each other. When that happens, trust, transparency, and collaboration across functional areas increases and everything just seems to work.

The communication gap between technical and nontechnical teams is big and getting bigger. It’s a huge emotional and productivity drain on everyone involved. Fixing that problem will do more for the health of our teams, organizations, and products than any number of Agile seminars, corporate mixers, or design thinking workshops ever will.

I’ve tried bridging the communication gap in a lot of ways. Some have worked well, others less well. My favorite approach so far comes from the field of system dynamics.

System Dynamics

Jay Forrester, a professor at MIT, developed the field of System Dynamics in the 1950s. Trained as an electrical engineer but working in the newly formed Sloan School of Management; Forrester started experimenting with ways to apply scientific techniques to problems in business.

As a venue for his research, Forrester worked with a handful of large companies. His goal was to solve seemingly intractable business problems. Not only did he succeed and help the companies he was working with, but he developed a new way to understand complex systems in the process. This approach is now called System Dynamics.

Forrester showed that, contrary to popular opinion, most of the problems that the companies were facing weren’t caused by external factors like competition or poor economic conditions.

Instead, they were created by causes and effects, feedback loops, incentives, and relationships within the companies themselves. By helping managers understand the internal structure of their companies, Forrester revealed how well-intentioned policies were actually causing problems they were trying to avoid. With that new knowledge, the managers changed their approach and fixed the problems for good.

How It Works

System Dynamics brings together two principles which, when combined, make complex systems like the inner workings of a business much easier to understand.

The first principle doesn’t need much explanation — visually representing data makes it easier to absorb. Graphs are better than tables.

The second principle comes from Forrester’s background in the sciences. In fields like engineering, real-world experiments can be expensive, difficult, and time-consuming to run. In those cases, simulating an experiment mathematically is a cheap and fast way to learn. Simulations take static models and give them immediacy and life.

Forrester’s insight was how well these two principles reinforce and amplify each other. Joining together visual representations of complex systems and the ability to model them mathematically lets you see how the system evolves over time. You can discover where the leverage points are within the system. And you can experiment with different approaches to changing how the system behaves.

For complex systems full of feedback loops (such as businesses and technology), System Dynamics is an amazing tool.

Modeling Software Systems

The model used in the rest of this article will be very familiar for anyone working in software development. It explores how code quality, refactoring policies, and waste impacts the amount of code a team can ship and maintain.