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.
