The Property of Complex Systems

Table of Contents

The Property of Complex Systems

This morning, while driving to work, I encountered a much longer traffic jam than usual. “Well, with such cold weather, everyone is probably driving more cautiously,” I thought, as I slowly crawled along the Łazienkowska Route. After several minutes, I noticed from a distance that there was an accident on the opposite lane, with police and paramedics doing their work. On my side, nothing particular was happening. But still… Drivers were simply slowing down to see what was happening on the other side. No one was stopping, they were just looking. And as a result, the stretch that usually took me 5 minutes this time took 20 minutes. After passing this point, the traffic sped up significantly and flowed normally.

Why am I writing about this? I immediately saw an analogy to software projects. Software projects – people, architecture, processes – form a complex system. Often, small changes, seemingly insignificant elements, have a tremendous cascading impact on what happens in the projects.

Perhaps one too many or too few decision points, a lack or abundance of documentation, a lack of assertiveness or permission to talk about mistakes, a lack of strict cooperation or too free cooperation without set rules can significantly reduce the efficiency of the entire process. It’s worth remembering this!

In the case of road traffic, the situation is somewhat simpler because it’s easier to measure - it’s speed and travel time on the same route. We don’t have this luxury in projects, where typically what is implemented is not as repeatable. However, we can approximate and compare by estimating tasks and adding a relative measure of task complexity (functionality).

A less formal method is points (points, story points), which are a relative unit used more for comparing the complexity of different functionalities than for an accurate analysis of complexity (which is extremely labor-intensive and would remain just a forecast). A more formal method (where much more precision is required in arguing the given estimates) can be multi-factor estimation methods and measuring tasks using function points.

Then we can observe whether our speed changes and how the introduced changes affect it.

(Text translated and moved from original old blog automatically by AI. May contain inaccuracies.)

Related Posts

The Natural Order of Refactoring Under the Microscope Part 1

Refactoring is an age-old problem—perhaps not the best word given the relatively short existence of software engineering as a discipline. Everyone knows refactoring should be done, but nobody seems to have the time for it.

Read More

Have a Clear Vision, Stick to the Intention and Adjust the Implementation

No matter if you are a tech lead, Scrum Master, Product Owner, or a member of the team, if you want to make your idea a reality, here is a very simple (and of course very difficult to implement) advice:

Read More
Antipattern: Adrenaline Junkie

Antipattern: Adrenaline Junkie

Understanding Project Pressure and Tension

I constantly wonder why situations arise where pressure and tension are generated in projects. One reason is that most projects are simply complex—you have to coordinate several, sometimes dozens of people, anticipate and plan in advance what will happen, and determine what resources will be needed. As a species, we’re not very good at detailed long-term planning (see: David Rock – Your Brain at Work).

Read More