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

Architectural Mantra

Those who attended JDD 2013 could see it live. For those who weren’t there or missed it, below you will find a presentation on the Architectural Mantra along with an extensive article. Set aside some time for this.

Read More

Technical Leader Worries: I Want to Build Trust in My Team but I Don't Want Them to Do What They Want

Understanding Trust in Leadership

Trust is a very big word and very often misused. Many leaders, in an attempt to build trust, feel obliged to allow people to do anything they want. However, they also wish to have some impact on how a task is completed.

Read More

Conversation with the Client

First Conversation with the Client

Today marks the beginning of a new project. As always in such cases, there is a hint of excitement in the team, as well as attempts to guess what the project will be about. We have some information, but nothing is certain yet.

Read More