Why Aircraft Carriers are not Agile

In Podcast #31 of Reversim, one of the podcasters (I think it is Ori) mentions this anecdote:
I once had the chance to talk with a consultant. When I asked him what he thinks about agile he said: 'Have you ever seen an aircraft carrier that was developed using an agile methodology?'

(Disclaimer: (1) The anecdote is stated in a somewhat vague manner. I took the liberty of rephrasing it into a concrete statement. Hopefully I got it right. (2) I am not saying that either Ori or Ran are in favor of the statement. They just mentioned it)

So, the topic of this post is this simple question:
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. The remainder of this post is just the rationale.

An aircraft carrier is one of the most complicated machines ever built by man. Still, there is one perspective wherein the complexity of an aircraft carrier is a mere fracture of the complexity of almost any computer program. I am speaking about the ability to reason about the machine from its blue prints.

If you take the blue prints of an aircraft carrier you can determine whether the thing will float or sink. It is a simple matter of volume vs. weight. Of course, calculating the volume or the weight from the blue prints is not always a trivial task, but it is still doable. In fact, one can use a computer to do this. Bottom line: the blue prints give a precise answer to the most fundamental question related to any vessel: will it float?

In computer programs things are different. Even if you take the actual source code you will not be able to get a precise answer to the fundamental question of programs: will it compute the correct output? It is not a difficult question to answer. It is an impossible question to answer. All the computers in the land will not help you answer this question. That is what Church/Turing had proven in the 1930s (I know I mention these guys in almost every post - but that's how I see things: all difficulties in software construction are due to the properties proven by these two).

Note that we are speaking about the source code. The blue prints (UML diagrams, design documents, whatever) provide even less information about the program than the source code. Therefore, they cannot provide any better answer.

Under these circumstances it is not surprising that agile methodologies which promote a trial-and-error type of process are on the rise. When you don't know how a machine will behave unless you build it and run it, the only viable option is to built it, run it, see what it does and make the necessary adjustments.

Going back to the original question, let's play this little experiment: Suppose we live in a universe where there is no practical way to determine whether a thing floats or sinks. There are some vague heuristic for building vessels that float, but every now and then ships sink as soon as they leave the dock. So, in such a universe

will you volunteer to go aboard an aircraft carrier that has been carefully planned but never left the dock?


14 comments :: Why Aircraft Carriers are not Agile

  1. 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."

  2. Confronting this sort of question ("Given inputs ___, does the program work?") in a continuous, automated fashion is precisely why some people are so keen on unit tests.

    Of course, that doesn't contradict the fact that a program's execution can't be perfectly checked without actually running it in some sort of test fixture.

  3. Note: with functional programming you can provide mathematical proof for your software.
    The first aircraft carriers did have some trouble with staying to float, because the tower is on one side, making one side heavier than the other, which was a real problem in the beginning. Other problems were: how to let aircrafts land safely, or how to prevent the ship to sink or burn down when under fire.
    The reason that aircraft carriers are not build via Agile methodologies is that aircraft carriers are more or less the same for the last 40 years. Software in new marine-boats might be written with agile methodologies though ;-) . In the beginning days of aircraft building, an iterative and/or prototyped approach could maybe have saved millions in both money and life's.
    (Disclaimer) I do not work for the marines or so, most information I know about aircraft carriers is from discovery channel ;-)

  4. Sorry I am a new reader...
    ... what are you referring to that "Church/Turing had proven in the 1930"?

    This stuff here:

    http://en.wikipedia.org/wiki/Church%E2%80%93Turing_thesis

    ?

  5. @Frank: I agree but I think it is tied to the main point. I think that changing requirements are a derivative of the fact that we cannot know in advance how the program will perform.

    @Wanja: Thanks. Highly thought provoking

    @Jonas: Yes. In short, Turing proved that there is no systematic way to know if a program will run into an infinite loop. This means that you cannot know if a program computes its outputs correctly, if two program are equivalent, etc.

  6. Aircraft carriers not only float, they aim to be unsinkable. How does this affect your thesis?

  7. "Even if you take the actual source code you will not be able to get a precise answer to the fundamental question of programs: will it compute the correct output?"

    This does not mean its impossible to have systems which verify the output of programs can be proved correct.

  8. Itay - you are using the Church/Turing thesis to reach an incorrect conclusion.

    If you have a problem, and you build an algorithm for it. You absolutely *can* prove its correctness.

    If you're algorithm is correct (granted), you can prove it is finite and correct, and you can evaluate its complexity.

  9. @Anonymous 1: It does not matter much. I took flotation as an example for a property that can be engineered successfully up front. If non-sinkable is such property then it is covered by the thesis. If non-sinkable is not such a property it is achieved by experimentation which means that even aircraft carriers are somewhat agile.

  10. @Anonymous 2: "If you have a problem, and you build an algorithm for it. You absolutely *can* prove its correctness."

    It seems like an incorrect analogy. What happens if your proof shows the algorithm is incorrect? You rewrite, sometimes 100% of it. Thus, the build-and-prove way is not an up-front design approach. It is a trial-and-error (agile-like) approach.

    However, proving correctness of algorithms is often non-practical (even in language such as Haskell), let alone in a multi-threaded settings. That's why agility promotes testing rather than proofs.

  11. I like this post a lot, the unpredictability of the software industry makes Agile the perfect choice. However, for large, complex, and traditional projects such as construction, then the process is classic and nearly always the same.

    Agile has its limitations that people should accept, it is meant for projects where neither you, nor the client is sure of the end result.

  12. @Project Management Hut: "Agile is meant for projects where neither you, nor the client is sure of the end result."

    In 99% of all project the client will want to change the end result once he sees it working. The primary reason for that is the inability to give a close-enough model of the end result at the early stages.

    In building construction, the architect can prepare a model which is pretty good approximation of the real thing and the client can then give feedback on that.

    In software, one would have to develop a prototype of the product to get the same level of approximation. This prototype will then be iterated over so the overall process will be quite agile.

  13. When the Oosterscheldekering had to be build in the Netherlands (to hold back the see), a scale model proved that the sand under the pillars washed away. Imagine the cost made when they skipped the small scale model. I think starting small and testing your expectations is always a good idea.
    We have many examples of other dutch construction-projects failing in time and budget too. So also in construction, start small and test your expectations. But know what you already know. We to expand our application big time just by adding the hibernate-package to it, knowing exactly what it can and can't do. No need for testing an already proved framework.

  14. This comment has been removed by a blog administrator.

Post a Comment