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

Clients Want to Be Agile...

Clients Want to Be Agile…

One of the recent meetings involved establishing (by me, MS) a way to collaborate with a client (details intentionally slightly modified or omitted, though based on a real case). The client (K) said:

Read More

Time for Assertiveness Training!

The Importance of Assertiveness

In my previous post, I discussed assertiveness in the context of time management. Upon reviewing various situations I’ve encountered, I can confidently assert that a lack of assertiveness (including appropriate communication) is the root cause of many other project issues.

Read More

Estimation Is Not a Commitment

Estimation Is Not a Commitment

You’ve probably heard that estimation is not a commitment. Sometimes in teams using estimation techniques, some form of accountability for the accuracy of estimation emerges. This is unfavorable for several reasons:
a) firstly, estimation is an approximation (with some probability), not a definitive result;
b) secondly, when accountability kicks in, project games emerge;
c) there are at least several factors causing estimation to differ from the actual time spent on a given task:

Read More