[caption id="attachment_199" align="alignleft" width="300" caption="Aircraft Carrier"][/caption]

Itay Maman tries to answer the question posed in the title:

Why aircraft carriers are not built using an agile methodology?

And my answer is this:
Because the engineers can know up front that it will float

That's it. That's the answer. That's the point I am making.

I think the question is a good one, yet I do not agree on the answer. The mistake Itay makes is to reduce the task of building an aircraft carrier to the question: "Does it float?"

I haven't been in any kind of military service. I have never been on an aircraft carrier (with the exception of a real cool flightsimulator with a real fighter cockpit). But I'd think the requirements for an aircraft carrier are rather complex. It should float. It should be difficult to hit with rockets or similiar, it should withstand hits with any kind of projectile, it should carry aircrafts and enable them to start and land. And of course it should allow the many women and man needed for the operation to live on the ship. You can't calculate this from the plans. And I am pretty sure that every single aircraft carrier is full of signs of improvisation where things didn't work as planned.

On the other hand: proving algorithms in enterprise software is just as doable as calculating if an aircraft carrier floats. The referenced proof that one can't write a program that predicts for every program if it stops after finite time is next to irrelevant. Because for the typical applications this question is answered rather easily (ignoring bugs). For a desktop application it's simply: It does stop exactly iff anybody clicks on the close icon.

One of the comments hints in the right direction:

Another reason that agile processes are not used in the construction of aircraft carriers is that people who sign the contract to purchase an aircraft carrier do not change the size and speed requirement after the ship has already been halfway completed. Nor do the bring back a ship that has already been delivered and say, "We need you to make the deck ten feet longer."

But I'd expect these questions to be rather typical: "Oh we have this new fighter, it needs a longer deck. Can you make it?" And the people building aircraft carriers will try to do it or at least make a proposal on how to fix the problem. Actually this is the same problem Architects have (the real ones with a capital A). Customer request last minute changes all the time in all businesses of the world.

So where is the difference between building Aircraft Carriers and Software?

The first difference is the cost attached to a change! The cost of a change consists of the following parts:

1. Cost of removing what is already there.
2. Cost of adding what is supposed to be there in the new version.
3. Cost of testing, taking care of side effects.
4. Cost of not being able to use the subject of change during the change.

Number 2 and 3 is more or less the same for aircraft carriers and software. But number 1 and 4 differ a lot. If you replace a piece of an aircraft carrier, you have to remove the original piece, it attached to the ship really well I'd guess. With software it is just hitting the delete button a couple of times. Also during the replacement work, your software is fully available (assuming you are not doing changes directly to a production database). Only when everything is done you have to deploy the software which might cause an outage for limited time. This is very different for aircraft carriers. You can't start on a carrier, when engineers took that catapult out to replace it with a stronger one.

So one real difference between software development and building an aircraft carrier or any other industry producing real physical artifacts is the cost of change.

Once you realize that fact, the next revelation is: The grass is greener on our side! Aircraft Carrier Builder have to plan extremely detailed and carefully, because everybody involved knows: Changes are expensive. They just can't make mistakes.

Very different for software developers: If we do something wrong the costs are only those attached for doing it the wrong way, which is rather cheap if you realize it immediately.

Therefore agile methods try to detect errors fast, by getting feedback from the customer as often and early as possible.The waterfall approach tries to prevent changes.

The second difference is in the process of automation: The software industry is the only industry that produces it's own tools. If a developer finds herself in a need of  a certain kind of tool, she has everything available to write it herself. Especially if she finds herself doing things multiple times, it is very likely this job will get automated soon.

A welder working on an aircraft carrier can't build a new version of welding equipment. She would need skills very different from the ones used in her day to day job.

How does this affect the choice between agile and not so agile processes? Simply put: in software development everything which is done twice gets automated. So most things we do we, do for the first time. Which in turn makes it hard to predict how long it will take. In an aircraft carrier, you can calculate how many km of welding you have to do, compare that to the time needed for a meter of welding and get a pretty good estimate for the full time needed. The effect gets even more extreme when you build two aircraft carriers. The time needed for the second one should be extremely close to the time needed for the first one. Very different in software: Ctrl-C Ctrl-V done.

So software projects are harder to predict, therefore an agile approach makes more sense, because you are doing a detailed planning only for a couple of days or weeks ahead.

The third and final reason for going agile with software projects, but not with aircraft carriers is: We are immature.  Well not the individuals, at least not each, but the industry as a whole. Depending on what exactly you consider a computer, the first one was build somewhere in the middle of the last century. Aircraft Carriers aren't that much older, but ships, rockets, flying devices and all the pieces (except the computers and software) making up an aircraft carrier are way older. Which again makes estimating much more difficult.

So these im my point of view the differences between classical industries and the software industry. But what are the consequences? What should we do about it?

1. Be happy that we are working in highly interesting, fast moving industry, that can fulfill customer wishes they couldn't even dream about 20 years ago.
2. Realize that while change is cheap, it isn't free.
3. While agile is the way to go for many projects it isn't for every one. If you are building software medical appliances, space ships, airbags or aircraft carriers you should think twice before going down the agile road.