As requirements change, the computer system changes along to satisfy the requirements. Maybe software engineers add new system components to satisfy those requirements. Sometimes, they opt to add logic to existing system components. Interactions increase, and complexity increases. Software engineers have to manage the complexity such that it is manageable for themselves and their successors. That way, the system can be easily extended and adapt to its constantly changing landscape.
A great deal of effort is spent on managing the complexity of computer systems. And with this effort, comes pragmatic wisdom. But what does the term computer system encapsulate? Where are the boundaries of the computer system?
Is the boundary the interface upon which we interact with it? One might want to include the infrastructure that the computer system runs on into our definition of the computer system. What about the release pipeline? Yep, also part of the computer system. The complexity of the release pipeline needs to be managed in a similar manner to the application logic.
The more we expand our conception of the computer system, the more places we can apply our wisdoms.
What about the people extending and maintaining the computer system? One could argue that they are a part of the system overall. Sure, maybe not the computer system but they are part of the system. One should apply the same philosophies that aid them in designing the computer system in designing the processes that guide the behaviors of the individuals working on the system.
From Wiki:
A system is a group of interacting or interrelated entities that form a unified whole. A system is delineated by its spatial and temporal boundaries, surrounded and influenced by its environment, described by its structure and purpose and expressed in its functioning.
We have our databases replicate as to not have a single point in failure. In the same way our computer systems are designed for redundancy, we should organize our teams for high redundancy. Make sure that more than one person knows how to kill that worker that might go haywire. That one person might be on a plane.
No one likes maintaining system components that have poor observability. Good monitoring leads to discovering issues before customers report them. In other words, before they get bad enough that you start losing money.
In the same way, you can monitor your own behavior and understand what your problems are. How much time are you losing on things that could be easily improved? What time are you waking up in the morning? How much coffee are you drinking? Collect data on yourself and address anomalies.
How scalable is the development of your system? How easy is it to get new people working on it and getting productive? No one wants to spend a month spinning up a new service. Likewise, we shouldn’t have a system that takes new engineers half a year to begin being productive.
The system that we work on, and the parts that we should be concerned with are the parts that we have any influence over. We can all influence each other. Maybe the next improvement you introduce into your system will start with the human components. Use the things you learn organizing the automatons that you control in organizing yourself and others.