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

Conferences Time

Autumn is usually a busy time full of conferences, and this year is no different. After a few interesting events like Devoxx Poland in Cracow, Codepot and Agile by Example in Warsaw, it’s now time for new experiences.

Read More

Code Cleanup: Not Just About Refactoring

Introduction

Blogspot unfortunately disappoints me when it comes to publishing source code, which is especially important for topics concerning coding style. Perhaps some of you have experience or ideas on this matter. I use the tool http://formatmysourcecode.blogspot.com/2006/02/paste-your-text-here.html, but still, Blogspot occasionally distorts the post.

Read More

Case of Scope Creep - A Simple Introduction to BDD Part 4

Introduction

In the dessert of JBehave, Behaviour-Driven Development, and the calculator (yay), we present the last part of our series.

Read More