There are many pleasures being involved in software development. I’ve been involved as a Business Analyst, Support Desk Lead and a Tester. Working with smart people, working with people that are passionate about doing a good job, meeting with likeminded people that enjoying discussing how things could be better (and actually do things to try and make that “better” happen). Of all my favourite things though nothing beats hearing that analogy that equates software development work to manufacturing or building. It just never gets old (you’re picking up on sarcasm at this point – I hope). As far as I can tell the discussion always seems to pop up in relation to estimation (and/or cost) and is often accompanied by the “oh shit” panic of a project in a bit of trouble. You know the sort of scenario:
Manager: I don’t understand the estimates we give. When I ask for a house to be built I get given a price, the house gets built and delivered within the date timeframes.
You: They’ve built that house before, right? I mean you’re asking for a new house but that house has been built before for others. You’ve seen the house, been in a display model of it. You’re asking for a copy of something that exists.
Manager: I don’t get your point. We’ve built software before. Our software exists.
You: We build software because the software doesn’t exist. Our clients ask us to build something new into the existing system. They have neither seen or experienced that functionality before in our system, and neither have we. We are not comparing like for like when we discuss software creation and house building. Perhaps you could ask your builder to add a swimming pool to your lounge room when they are half way through the build.
……and so the discussion goes until the inevitable conclusion where the analogy lives to fight another day.
When we compare thought/knowledge work (software development) to the manufacturing or building analogy it is accepted, by many, as a flawed comparison. That we are comparing “apples and oranges”. We can’t compare thinking to a machine stamping out widgets. When we are doing this we are comparing, what I’ll call “determined repeatability”, to the creation of something new. “Determined repeatability” is possible because we have spent time developing approaches, formulas, processes and formed them into a chain that produces what we (more specifically, our clients) desire. We can continue to process these widgets infinitum (as long as market forces maintain a demand). But market forces can be fickle, so can resourcing inputs. What happens if one of these changes and our processing chain loses its “determined repeatability”? What if the widget needs an update with the addition of new attributes? I wonder, is there a useful analogy if we change the target area of the analogy focus? I think when we compare the creation of software to manufacturing a widget we miss that the widget required research and development. Before the widget there wasn’t a widget. Someone had to spend time and money creating it. Now that the widget requires new features the “cut and stamp” process is disrupted. We have lost “determined repeatability” In this phase we potentially have a useful analogy with software development. In this phase of manufacturing we see thought, iteration, experimentation, exploration, failure, learning and finally a product that can be produced “cookie cutter” fashion.
I like aviation, actually more than like. It mystifies me even though I have a basic understanding of the forces at work. I can (and sometimes do) spend hours watching the big birds take off and land. To me it is a graceful blend of man and nature working together (leaving aside the engine emissions debate). The Wright brothers famous flight was on December 17 1903. On April 2005, a jet that stretched further than the Wrights’ first flight, took its own first flight. In slightly under a century it is a mighty impressive demonstration of human endeavour. If you’re interested, you can buy an A380-800. The average list price for one of these is a cool USD432.6 MILLION. (Personally I’m thinking of spending on the Boeing 787 Dreamliner. I can get 2 of those for the price of a single A380). I guess what I’m getting at here is that I can get a very sophisticated, highly technically complex aircraft for a known price and a known delivery date. As much as this sounds like it underplays the technology, at this point, the A380 is produced “cookie cutter” style, it’s a known quantity. When we compare software development to this, it “fails to fly”(pardon the pun).
Now let’s go back in time a bit the A380 does not exist. There are potential customers but the aircraft is not a reality. Let’s also remember this is not the first aircraft either. This is true for the Airbus company and a large and relatively thriving industry. You could be slightly flippant and say “they are just making a variation of what has been done before” (ever heard that before about software development – I have). There is no shortage of experience and knowledge but, and this is important, they are going to a place they have not gone before. This will be the largest commercial aircraft ever. Even if it wasn’t distinguishable on just that aspect it will be made with new age materials and technology. Some have been used before, some are new.
So how did it all go? You might know the answer, or have some knowledge of the situation, but in summary. Not so well. Let’s start with some headliners.
Originally scheduled for delivery in 2006, the aircraft’s entry into service was delayed by almost 2 years and the project was several billion dollars over budget.
There must have been some fascinating boardroom discussions as the project travelled along. I think it is worth re-iterating that this is a company that builds incredible aircraft, they employee knowledgeable, capable people. They have a history of building aircraft. They have a strong reputation. How could this go wrong?
At the heart of the problems were difficulties integrating the complex wiring system needed to operate the aircraft with the metal airframe through which the wiring needed to thread. With 530Km of wires, cables and wiring harnesses weave their way throughout the airframe. With more than 100,000 wires and 40,300 connectors performing 1,150 separate functions, the Airbus A380 has the most complex electrical system Airbus had ever designed. As the first prototype (registration F-WWOW) was being built in Toulouse France, engineers began to realize that they had a problem. Wires and their harnesses had been manufactured to specification, but during installation the wires turned out to be too short. Even though the cables were at times just a few centimetres too short, in an aircraft you can’t simply tug a cable to make it fit. As construction of the prototype continued Airbus management slowly came to the realization that the issue was not an isolated problem and that short wires was a pervasive issue throughout the design.
A single miscalculation. There were reasons behind the miscalculation (a chain of errors), but none the less, the impacts were really something. It also meant “back to the drawing board”, let’s examine and understand the failure, let’s find other ways to meet our objective. Who the hell saw that coming? The answer is nobody. If somebody had seen it coming it would have been prevented before it became a major problem.
I can’t prevent people wanting to make comparisons between software development and manufacturing or building. That’s beyond my control. What I can have some control over is my response. That response will now be to acknowledge there might be some validity but change the focus to the development phase, where there are similarities, and not the completed “cookie cutter” production cycle where there are few, if any, similarities. If you want to make a comparison between production line output and software development, then maybe we should be discussing the physical delivery of the completed code after completion of development. That just might be an equivalent analogy with stamping out widgets.
Thanks for dropping by
Paul
A big thank you to Lee Hawkins for his review and feedback
(@the rockertester, https://therockertester.wordpress.com/about/)
@Beaglesays 