Agile Bridge Analogy

Home

News: Agile Bridge Analogy

  1. Agile Bridge Analogy (13 messages)

    It is quite common to make analogies between the IT industry and Civil engineering. Developers often compare software development and design with construction projects; for example, the importance of having a blueprint and following known successful practices. I have some hesitations about using analogies between these industries. I find the resources used by both industries fairly different and for that reason the analogies can create false expectations and reasoning. Nevertheless, I have been successfully using the analogy of building a bridge for explaining Agile development. Read the rest at http://agiletips.blogspot.com/2008/07/agile-bridge-analogy.html

    Threaded Messages (13)

  2. Re: Agile Bridge Analogy[ Go to top ]

    So basically you end up with a crappy wooden bridge unable to support the weight of a large truck or a train? If this a good analogy for Agile, it actually implies that it's useless for really tough problems. Could you build a bridge from Manhattan to Brooklyn this way?
  3. Re: Agile Bridge Analogy[ Go to top ]

    "Could you build a bridge from Manhattan to Brooklyn this way?" Perhaps you should phrase the question in the form of a requirement. "Could you provide access to Manhattan from Brooklyn using an agile methodology?". Sure in the first iteration you would use a Ferry Boat. In the next Iteration you would upgrade the Ferry Boat to a Steam Power ferry. As demand increased you would create a fleet of ferries and add more Ferry Landings on the Brooklyn side and the Manhattan side. Finally as demand surged you would begin the construction of the bridge while continuing to provide service( provide value) to your stakeholders(Brooklynites needing access to Manhattan). By the way this happens to be the actual historical evolution of the Brooklyn bridge. If the city had attempted to build the bridge before the economic base of the city had been established the bridge would likely have been cancelled due to funding...just like many large waterfall IT projects. You just need to have a little more imagination, and perhaps a few interests outside of IT and engineering to get use out of this analogy. Sincerely, Another Overpaid Enterprise Architect Who Delivers :)
  4. Re: Agile Bridge Analogy[ Go to top ]

    "Could you build a bridge from Manhattan to Brooklyn this way?" Perhaps you should phrase the question in the form of a requirement.

    "Could you provide access to Manhattan from Brooklyn using an agile methodology?". Sure in the first iteration you would use a Ferry Boat. In the next Iteration you would upgrade the Ferry Boat to a Steam Power ferry. As demand increased you would create a fleet of ferries and add more Ferry Landings on the Brooklyn side and the Manhattan side. Finally as demand surged you would begin the construction of the bridge while continuing to provide service( provide value) to your stakeholders(Brooklynites needing access to Manhattan). By the way this happens to be the actual historical evolution of the Brooklyn bridge.

    If the city had attempted to build the bridge before the economic base of the city had been established the bridge would likely have been cancelled due to funding...just like many large waterfall IT projects.

    You just need to have a little more imagination, and perhaps a few interests outside of IT and engineering to get use out of this analogy.

    Sincerely,
    Another Overpaid Enterprise Architect Who Delivers :)
    Thanks. I think you brought the correct view to this topic.
  5. Re: Agile Bridge Analogy[ Go to top ]

    Ugh. Enough of the engineering analogies - they just don't fit!! In 2008, software development is still a creative, collaborative design process. It is NOT house construction. It is not bridge construction. Alistair Cockburn has a great presentation from back in 1999 on Software Development as a Cooperative Game. It's a much better description of what it really takes for a team to build a system. Dave Rooney Mayford Technologies
  6. Re: Agile Bridge Analogy[ Go to top ]

    Ugh. Enough of the engineering analogies - they just don't fit!!

    In 2008, software development is still a creative, collaborative design process. It is NOT house construction. It is not bridge construction.

    Alistair Cockburn has a great presentation from back in 1999 on Software Development as a Cooperative Game. It's a much better description of what it really takes for a team to build a system.

    Dave Rooney
    Mayford Technologies
    Exactly! Besides, the process of building software in organizations that like the house building- or conveyor belt metaphor quite often go something like this: - Have lots of people write stacks of paper. - 6 months later, with nothing yet delivered, start throwing mediocre warm bodies at the problem and have them try to make sense out of said documents. - No one is able to make sense of the documents, because software is somewhat more abstract than a house. - Panic, start hacking away frenetically in a completely disorganized ad hoc fashion, while completely ignoring the documents previously written. - Try to throw a useless pile of spaghetti code over the fence and con the client into accepting it. Software is about people and their habits, more than any defined process, because it is inherently built in an emergent fashion. nine times out of ten when a lot of up front planning is done and documented, said documents eventually become entirely ignored, and are at most read by some "project review panel" that want to add their technically unqualified 5 cents to the design (to complete the mess with "design by committee").
  7. I don't get it[ Go to top ]

    I don't get it. The point of agile development is that development should react to change quickly and often, while a bridge generally is built slowly and methodically and is intended to last for decades in it's final state. The evolution of the bridge you describe would take decades if not centuries to occur and would require exponentially more time, effort, planning, and money between each iteration. With bridge development often used as examples of govt boondoggles and excessive waste, it's hardly what I would call a good analogy of agile development.
  8. Point is to bring value earlier[ Go to top ]

    The analogy is used to simply point out the benefits of bring value as soon as possible. You can plan a great software to be developed in some time but the risk of failure (the bridge not built) would be a waste of time and money. On the other side, if you develop it 'incrementally', even if you take 10 years to reach your 'dream point' - even if you can't reach it at all - the artifact you delivered is at least useful. And this is the worst scenario ;) Cheers, Carlos
  9. Okay. It's an adequate analogy on incremental or iterative development, but I don't think it really captures what agile development is. Iterative development is an aspect of agile development but is not what defines it. But then again, no analogy is perfect, and I guess if you need an analogy to explain agile development, you're already dealing with someone who can only understand such concepts on the most simplistic level ;-) - anything more subtle will only confuse or be lost on them.
  10. It is quite common to make analogies between the IT industry and Civil engineering. Developers often compare software development and design with construction projects; for example, the importance of having a blueprint ...
    This statement needs some serious substantiating. The closest thing to agile bridge-building I could find was Weinberg's Second Law: "If builders built houses the way programmers built programs, the first woodpecker to come along would destroy civilization." :-)
    and following known successful practices. I have some hesitations about using analogies between these industries. I find the resources used by both industries fairly different and for that reason the analogies can create false expectations and reasoning.
    So, what you do is make an unsubstantiated claim (in this case just a false one) and than argue it on the ground being false. That's agile blogging for you :-) Regards, Slava Imeshev Cacheonix: Clustered Java Cache
  11. Is this necessary?[ Go to top ]

    Without criticizing the author, it seems clear that this analogy, like others of its kind, remains unsatisfying. To be frank, I think that the attempt to understand (or perhaps I should more properly say define?) software development as a kind of engineering is misguided. It is not only that the activity as it stands lacks the rigor and fund of knowledge that separates engineering from craft; that may come in time, although I do not think so. The essence of the activity seems to me to be more akin to writing a story or drawing a picture than to a scientific discipline. This is true whether a team of people or one person carries out software development. My view is that the idea that software development has anything to do with engineering stems from two sources. First, software development was at first carried out by engineers, people who designed and built computers. Second, I think that this is an apologist approach taken (with good intentions, in my belief) in order to justify the worth and prestige of software development by linking it with engineering activities held to be of value to society. The idea reminds me of an argument once proferred by Mikhail Botvinnik, one of the great Soviet world chess champions. If physics is a science, he stated, and acoustics is a branch of that science, then music is an art that illuminates the beauty of that science; and if mathematics is a science, then chess is an art that illuminates the beauty of that branch of mathematics called logic. It was an attempt to justify the value of playing chess by describing the game as an art form, but I have always felt that it was misguided. Chess, I felt, if it truly is of value to society, needs no justification outside itself. It is a thing unique, a game and an art and a sport and something else, not susceptible to analysis in terms of any other human activity. I think this is true of software development as well. I don't think it is an engineering discipline at the moment. I'm not sure it can be called an art, either, nor is it always a business. To me software development seems a unique activity that combines elements of art and science and linguistics - programming languages are exactly that - and requires of its best practitioner the ability to work with and harmonize an extraordinary number of facts, technical and human, present and future, about the enviroment in which the software will work. I don't know that there is a good analogy with any other human activity. Personally I have no problem with this view. I consider it entirely possible that new technologies will allow humans to create entirely new activities with no precedents. I think that software devlopment will come into its own only when its practitioners give up apologist arguments and comparisons and demand for themselves the respect they deserve, as creators of a new and unique thing of value to society which needs no legitimacy from kinship with engineering or any other branch of the professions. On a more pragmatic level, I think that new activities require new methods for planning and monitoring them, new methods for determing good work from bad, and new methods for training, which may not exist. It is a daunting challenge, but it is, after all, the same challenge faced by engineers over the last few thousand year and by medical professionals since the last century. I believe that software developers, in order to meet that challenge, must accept the fact that our work is a unique human activity.
  12. Re: Is this necessary?[ Go to top ]

    Ethan,
    Without criticizing the author ...
    I believe political correctness has killed those little stems of was thought to be engineering in software.
    I think that software development will come into its own only when its practitioners give up apologist arguments and comparisons and demand for themselves the respect they deserve, as creators of a new and unique thing of value to society which needs no legitimacy from kinship with engineering or any other branch of the professions.
    I like this one. Actually, I love it. What do you think about Software Artist (as in The Art of Computer Programming) as a contrary to non-existing Software Engineer? Regards, Slava Imeshev Cacheonix: Distributed Cache for Java
  13. Re: Re[ Go to top ]


    ... What do you think about Software Artist (as in The Art of Computer Programming) as a contrary to non-existing Software Engineer?

    Regards,

    Slava Imeshev
    Cacheonix: Distributed Cache for Java I do think that the view of software development as an artistic activity has some validity, at least at this point in its history. Certainly the design process has has strong similarities. However, I think the comparison is limited. For one thing, it seems to me that software developers can almost always produce something considered to be of value by their audience, which, of course, is not always true of art. In fact the existence of objective criteria for evaluating results is the main thing that prevents me from going along and saying that, yes, software development is art. My views on this comparison, to be frank, are colored by the fact that I would prefer software development to be viewed as more reliable than most arts ... that is, I would prefer to avoid the giving the impression sometimes expressed that the results of artistic activity are wildly unpredictable and of dubious value. My opinion is that the results of software development are more reliable than art but less reliable than engineering ... obviously a personal view.
  14. Re: Re[ Go to top ]

    I think the comparison is limited. For one thing, it seems to me that software developers can almost always produce something considered to be of value by their audience, which, of course, is not always true of art.
    Well, if it is true that 80% of software projects are to fail, this is more like "almost always not". Regards, Slava Imeshev