|
Sponsored Links
Resources
Enterprise Java
Research Library
Get Java white papers, product information, case studies and webcasts
|
News
News
News
|
Messages: 13
Messages: 13
Messages: 13
Printer friendly
Printer friendly
Printer friendly
Post reply
Post reply
Post reply
XML
XML
XML
|
 |
Agile Bridge Analogy
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
|
|
|
Message #264171
Post reply
Post reply
Post reply
Go to top
Go to top
Go to top
|
|
Re: Agile Bridge Analogy
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?
|
|
|
Message #264174
Post reply
Post reply
Post reply
Go to top
Go to top
Go to top
|
|
Re: Agile Bridge Analogy
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
|
|
|
Message #264176
Post reply
Post reply
Post reply
Go to top
Go to top
Go to top
|
|
I don't get it
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.
|
|
|
Message #264177
Post reply
Post reply
Post reply
Go to top
Go to top
Go to top
|
|
Point is to bring value earlier
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
|
|
|
Message #264248
Post reply
Post reply
Post reply
Go to top
Go to top
Go to top
|
|
Re: Agile Bridge Analogy
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").
|
|
|
Message #264271
Post reply
Post reply
Post reply
Go to top
Go to top
Go to top
|
|
Re: Point is to bring value earlier
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.
|
|
|
Message #264600
Post reply
Post reply
Post reply
Go to top
Go to top
Go to top
|
|
Re: Agile Bridge Analogy
"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 :)
|
|
|
Message #264604
Post reply
Post reply
Post reply
Go to top
Go to top
Go to top
|
|
Re: Agile Bridge Analogy
"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.
|
|
|
Message #264610
Post reply
Post reply
Post reply
Go to top
Go to top
Go to top
|
|
Weinberg's Second Law and Agile Blogging
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
|
|
|
Message #264618
Post reply
Post reply
Post reply
Go to top
Go to top
Go to top
|
|
Is this necessary?
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.
|
|
|
Message #264622
Post reply
Post reply
Post reply
Go to top
Go to top
Go to top
|
|
Re: Is this necessary?
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
|
|
|
Message #264626
Post reply
Post reply
Post reply
Go to top
Go to top
Go to top
|
|
Re: Re
... 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.
|
|
|
Message #264655
Post reply
Post reply
Post reply
Go to top
Go to top
Go to top
|
|
Re: Re
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
|
|
|
| New content on TheServerSide.comNew content on TheServerSide.comNew content on TheServerSide.com |
|
|
Reza Rahman continues to explore the features of the proposed JSR 299, Contexts and Dependency Injection for Java EE (CDI). When approved, it promises to be a key feature of Java EE 6.
(January 21, Article)
Ted Neward is an independent consultant specializing in high-scale enterprise systems, and an authority in Java and .NET technologies. He is the author and co-author of several books, including Effective Enterprise Java. At TheServerSide Java Symposium in March, he will be presenting sessions on pragmatic architecture, ECMAScript and Scala.
(January 15, Article)
Now that Oracle is absorbing Sun Microsystems, there mixed views on what should come of the Java Community Process (JCP). While some say Oracle should become the new steward of Java and keep the JCP much as it was, others argue that it may be time to open-source this widespread language.
(November 24, Article)
Reza Rahman explores the features of the proposed JSR 299, Contexts and Dependency Injection for Java EE (CDI). When approved, it promises to be a key feature of Java EE 6.
(November 2, Article)
SAML is an XML-based standard for exchanging authentication and authorization data between security domains. The single most important problem that SAML was created to solve is the Web browser Single Sign-On problem. Many organizations are debating whether to stay with version 1.1 or move to 2.0. This article makes observations about both options.
(September 28, Article)
Joe Ottinger takes a look at how people learn, and applies it to the practice of programming. He notes that understanding how people learn is an essential part of working in a programming team.
(September 22, Article)
Stephen Maryka gave us an article about the Asynchronous Web and posed a number of questions that get examined like an approach to delivering Asynchronous Web capabilities through extensions to existing Java EE technologies.
(July 14, Article)
JavaServer Faces Flex goal is to provide users capability in creating standard Flex components, part of flexSDK which is open sourced through MPL license, as normal JSF components. This article by Ji Hoon Kim will provide an overview of creating a simple multilingual JSF page consisting of JSF Flex tags.
(June 29, Article)
In this session Jeff explores the key characteristics of successful SOA projects. He covers some of the patterns, and anti-patterns, tool sets, and strategies that he himself learned the hard way. Last, he provides a strategy and blueprint for achieving a high likelihood of success in your SOA project.
(June 23, Tech Talk)
Ari Zilka, CTO of Terracotta, Inc., talks about the new features in Terracotta 3.1, announced during JavaOne and available now.
(June 15, Tech Talk)
In this Tech Talk, Josh Long explores an integration challenge using Spring Integration and walks through the implementation, employing and expanding on the basic patterns of Enterprise Application Integration to tie together components into a function integration solution, and then demonstrates how Spring Integration helps address the integration requirements.
(June 15, Tech Talk)
In this Tech Talk, David Geary teaches you: The basics of Google Web Toolkit; How to implement Ajax-enabled applications in Java; Internationalization; Hooking into the browser history mechanism; Remote procedure calls.
(June 4, Tech Talk)
Jon Kern discusses the best architecture/technical solutions and ensure that they are repeated by all developers. By tackling the architecture up-front in a serial manner, subsequent parallel development will be much more manageable and predictable.
(May 28, Tech Talk)
This keynote describes the frustrations of modern knowledge workers in their quest to actually get some work done, and solutions for how to guard yourself against all those distractions. Neal Ford talks about environments, coding, acceleration, automation, and avoiding repetition as ways to defeat the misguided attempts to sap your ability to produce good work.
(May 26, Tech Talk)
Gil demonstrates how new, aggressive uses of already abundant compute capacity by common applications offer competitive value for application designers.
(May 21, Tech Talk)
Chris Keene introduces WaveMaker as a new way to automate the ability to generate Hibernate classes in order to more quickly bring OR mapping into an application.
(May 19, Article)
Mastering EJB was one of the original and most influential EJB books in the industry. Mastering EJB III now returns with two new expert co-authors, updated for EJB 2.1 and 30% new chapters including security, integration, best practices, open source, and more.
(Book PDF Download)
The Application Server Matrix is a detailed listing of J2EE vendors and their application server products, with information on latest version numbers, J2EE spec support and licensing, pricing, platform support, and links to product downloads and reviews.
(Application Server Comparison Matrix)
|
|
