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

Is Poland Christ of Nations?

I recently came across a very interesting article about the pitfalls of the Polish style of management and its historical roots. It is more generic than just IT but includes aspects of participatory management, such as Agile practices. If you understand Polish, you can read the article here.

Read More

Natural Order of Refactoring Explored Part 2: Compose Method

Compose Method

Analyzing methods, such as the one presented in Part 1, often leads us to understand the main points of the algorithm contained in them. This insight paves the way for the next step: try to split a large method into smaller steps by extracting them into separate methods (refactoring using the Extract Method). Thus, the original method will consist of a sequence of calls to these new methods. With the right naming conventions, you can achieve code that reads like a book.

Read More

Renounce Nothing, Attach to Nothing...

Renounce Nothing, Attach to Nothing…

Today I experienced an “AHA” moment in a certain area. Since the topic is universal, I decided to share it. This is somewhat a continuation of a post from a year ago.

Read More