[fghfghfghfghfgh]

Complexity exists in interaction between parts - not necessarily the parts themselves. Breaking down a project do not take those interactions into account.

Even if we were to try considering interactions we would fail. Like the weather, and other topics in the complex systems domain, software is sensitive to initial conditions. A small change in input (change in data or code) creates a large change in output.

We generally accept the upper bound on weather forecast to be 7 days and even then we might bring an umbrella just in case. Forecasting software many months into the future is futile - if taken at face value. Used as a general guideline it is usually ok.

A paradigm shift is needed. Both inside and outside the industry. Software is not industrial construction, hence the same logic (project management) do not apply.

Software is creation, conduction and orchestration. Not production or manufacturing. We are not teams of architect, builders and operators. We are musicians in a orchestra.

How long does it take to write a symphony?

[DesiLurker]

I agreed with you all the way until the last part about symphony, that is how you lose the attention of managers and leader types. majority of software is not a symphony rather a race car held together by ziptie and ducktapes just well enough to give a feel of something big in behind the curtains.

this is especially true if you consider the incremental work projects take on. THAT incremental work IS forecast-able. problem is often all the information need to be able to make that forecast is not in one place & the discovery process is often left unaccounted accidentally or on purpose to commit to tighter deadlines. add to that changing requirements and you have the state of software estimation we are in.

[fghfghfghfghfgh]

You're right - not the best analogy in this case. Not sure about the race car though. I will think about that. Analogies aside...

Let's agree that estimation is possible to a certain degree. We know this and accept the inherent uncertainty.

Modern project management is whole sale copied from industrial construction and manufacturing. It seems no one stopped to ask whether the same logic applies to software creation. And it doesn't.

The business side of IT is stuck in a mental model build on construction and manufacturing. Yet the process of creating software contains neither of those concepts with the exception of automated build and deploy (and costs for those are negligible).

It is also interesting that no distinct vocabulary for software exists. We build, deploy, construct, have factories and so forth. Again copied from disciplines which are complicated - but not complex.

It is not possible to obtain the information you refer to by analysis. That's a property of a complex system. Analysis of parts neglects the interaction between parts and in software more or less everything is connected.

This is one of the reasons why we cannot forecast weather and why we cannot reliably estimate software.

Now, if I start my explanation this way I'm also sure to lose their attention. So what do we do? Which intellectual approach will captivate these people, retain their attention and at least plant a seed of doubt in the established way of working?