The software development process and chaos theory

Over the weekend, I was talking to a non-software friend, and he asked what the big deal was about this whole software “engineering” thing. He’d been working in the manufacturing industry (he makes iron-ore furnaces) for many years, and said they’d solved the variability problem. They could make the furnaces within really small tolerances – and he could predict how long it would take. And, it would pass the levels of quality they’d set up for everything they made.

The fact of the matter was, as I explained to him, that it was impossible to control the effect of variability in the software process. Sure, Agile methods help many things – like setting up a constant heartbeat of 2-4 week iterations, providing a constant supply of jobs (stories) that need to be worked upon, ensuring constraints are identified and optimized etc.

However, even the smallest of changes can ripple into a totally different outcome. It’s like the whole thing about the butterfly beating its wings over the east cost of the United States – and it causing a hurricane in Japan. This is most evident if you try the thought experiment of having the same team build the same software twice in a row. The end result will be fairly different in each case – and certainly, the path taken will be very different.

Small variations, like some critical resource being on vacation on particular and different days, will cause changes in the schedule and dependencies that could potentially cause more significant changes in the overall project. Certainly, things like a different design (in the code) would cause different response times towards the various requirements as they came down the pipe. Different pairs of developers working on the same stories would result in different outcomes – maybe even different bugs. Heck, even the same developer coding the same thing twice would do it differently (right, guys?)

Given that these types of changes are arbitrary and therefore bound to happen, it is unreasonable to expect that software can be created (and the process controlled) to produce completely predictable results.

Just something to think about when trying to understand software development! And yes, I know it’s called complexity theory now, but chaos still sounds cooler.

4 thoughts on “The software development process and chaos theory

  1. ” … some critical ***resource*** being on vacation …” . hmmm.
    The conversion to the dark side is complete ? 🙂

  2. I think that the main difference between software engineering and manufacturing is that most of the phases of a software project that have to be performed by humans are creative design activities. The manufacturing part of software is done by the compiler or build script and is reliable, predictable and repeatable.

    I imagine that the requirements/specification/design part of producing an iron-ore furnace is almost as variable as the requirements/specification/design/code part of producing software.

  3. I found this post while doing a Google search and thought I would leave a comment. For the last few years, I have been building dynamic computer models to study the effects of chaos/complexity theory in software processes. Your intuition is right on the mark. However, when people discuss whether there is a difference between a manufacturing process and software development, I like to describe (now) that there are five attributes that significantly impact the outcome in software development that manufacturing does not have to deal with (much). These are:
    1) Dynamics (a software project is highly dynamic)
    2) Nonlinearity (the relationships between variables in a software project are not linear)
    3) Openness (a software project is connected to its environment)
    4) Adaptation (people constantly adapt and learn, which is why we can’t do controlled experiments of developing the same project twice)
    5) Non-determinism (no one has been able to identify any specific rules or heuristics people follow when making decisions that affect outcomes on a project; that is, people are emotional creatures, machines are not)

Leave a Reply

Fill in your details below or click an icon to log in: Logo

You are commenting using your account. Log Out /  Change )

Google photo

You are commenting using your Google account. Log Out /  Change )

Twitter picture

You are commenting using your Twitter account. Log Out /  Change )

Facebook photo

You are commenting using your Facebook account. Log Out /  Change )

Connecting to %s