Introduction

It’s naïve to think of software as a static system. Static systems are those that do not change in response to external factors. However, I argue that truly static systems are exceedingly rare. Consider furniture, books, or other objects in your home—they might seem static at first glance. But one factor changes them all: time.

Time is the universal force that alters everything. Imagine a piece of furniture crafted today. How will it look 100 years from now? Or 200 years? We see many antiquated buildings that have endured for decades, even centuries, but they are not immune to change. Over time, cracks may form in the walls, and pipes installed a century ago may deteriorate. Time is a relentless and influential external factor, and no system, no matter how static it seems, is exempt.

The same applies to software. Whether you make code changes or not, the passage of time affects software. Systems degrade, dependencies become outdated, and performance may decline. Time alone transforms even seemingly unchanging software into a dynamic system.

Dynamic systems are inherently subject to change. They evolve in response to external variables, internal behaviors, and time.

Given that systems are rarely static, how should we approach thinking about them?

To understand systems effectively, you need to consider both the big picture and the small picture—often referred to as the macro view and the micro view.

Developing a mindset for system thinking takes experience, and often, the best way to learn is by building a system yourself. Every system exhibits certain properties, and the manifestation of these properties determines how the system will behave.

System Thinking in Software

Usually, when it comes to software, there can be two types of feedback loops. One that is automatic and other that is manual. Automatic is mostly when the system adapts based on the scenarios it is in and how it has acted based on the input. With the advancement of technology, we have seen a self-healing systems and that is mostly automatic feedback loop. The example that comes to mind is kubernetes auto scaling feature.

Kubernetes auto scales up the pod based on the load it sees on the system and scales down when the load on the system goes down.

On the other hand, software serves a customer and customer provides a feedback about what the software is doing and what not. Based on that feedback, an engineer can tweak the system to behave differently for the customer. That’s manual feedback.

System thinking often involves observing events or data to identify patterns of behavior over time. This will surface the underlying structure that triggers those events.

Conclusion

In this post, I covered some thoughts about system thinking. System thinking in software is even more critical when building a distributed system. An experienced engineer will always look at macro view while making decisions for micro.