aspose file tools*
The moose likes Agile and Other Processes and the fly likes Popularity of software desing methods Big Moose Saloon
  Search | Java FAQ | Recent Topics | Flagged Topics | Hot Topics | Zero Replies
Register / Login


Win a copy of Spring in Action this week in the Spring forum!
JavaRanch » Java Forums » Engineering » Agile and Other Processes
Bookmark "Popularity of software desing methods" Watch "Popularity of software desing methods" New topic
Author

Popularity of software desing methods

Peter Braun
Ranch Hand

Joined: Feb 09, 2005
Posts: 57
Hi!

Do you know any sources about popularity of software desing methods?
For e.g which are the most popular and why, how many companies use them?

Thanks in advance:
Peter
Kishore Dandu
Ranch Hand

Joined: Jul 10, 2001
Posts: 1934
Like any reliable system in the world needs proper design, software also needs reasonable levels of efforts in the design stages.

There are different ways to go after software design. Many are process oriented and will help the longterm viability of the system that is developed.

Regarding how many companies are using software design, I would perceive all the sane development teams utilizing different design aspects.


Kishore
SCJP, blog
James Coplien
author
Greenhorn

Joined: Oct 26, 2004
Posts: 22
I recommend you contact Alistair Cockburn of the Cutter Group (also of Humans and Technology.) He did his Ph.D. last year in Norway on the efficacity of various design methods. His conclusion: You can't take an off-the-shelf method and make it work. You need to start with principles and tailor the solution to your organization.

This leaves out high-context solutions that overconstrain the solution, such as XP. (For all their bad press, neither the CMM nor ISO 9001 are really high-context methods!) It begs for the solutions that one finds not only in Agile methods, but in Adaptable methods as well.

In the early days of Agile we equated it with Adaptable, but now that we see Agile projects that have problems with adaptability, the latter is receiving some attention -- and Alistair is the poster child for this effort.


James O. Coplien<br /> Object Architect, DAFCA, Inc., Framingham, MA<br /> Visiting Professor of School of Informatics, University of Manchester<br /> <a href="http://users.rcn.com/jcoplien/" target="_blank" rel="nofollow">http://users.rcn.com/jcoplien/</a>
Peter Braun
Ranch Hand

Joined: Feb 09, 2005
Posts: 57
Thanks for your answer.

I'm sure every development team has it's own development method tailored for their personal needs. I'm curious which method is it based on. I suppose it depends on projects they work on.

What is difference between Adaptable and Agile? I have been always read about Agile.

Are Ph.D. dissertations free to read?

Peter
James Coplien
author
Greenhorn

Joined: Oct 26, 2004
Posts: 22
"Agile" means the ability to move quickly and to adjust to changes (in requirements, etc.) "Adaptable" means that something can be tailored to an existing culture. Both have to do with the notion of fitting one thing to the other, I guess. "Agile" is about fitting a method to changing customer whims. "Adaptable" is about changing the method to suit the organization and its customers.

Many "Agile" methods force the enterprise and its customers to bend to fit the method; the methods do not adapt to the context. These are high-context methods. Alistair Cockburn calls them "high ceremony methods." XP is one of the highest ceremony methods, and least adaptable methods, there is. It's their way or the highway. Of course, it hasn't worked out that way: everyone and his brother calls what they do: "XP." And the XP police aren't interested in chasing down those who claim to follow the Dogma: they are just interested in differentiating themselves from The Heretics.

However, the Agile discipline associated with folks like Alistair Cockburn and Jim Highsmith is adaptable. The Organizational Patterns are also adaptable--that is the very essence of patterns.

Most Ph.D. theses these days are on the web. I'm sure Alistair can send you an electronic version. Send me an Email if you can't find his.
Scott Ambler
author
Ranch Hand

Joined: Dec 12, 2003
Posts: 608
A couple of agile "design" approaches:

Test driven development, see Intro to TDD which includes links to a couple of great books. With TDD your unit tests effectively become part of your detailed design artifacts.

Agile Model Driven Development (AMDD) which defines an agile approach to modeling and documentation. Agile Modeling defined a collection of principles and practices which can be tailored into software development processes such as XP, RUP, Scrum, ... to improve your modeling/documentation approach. It is supposed to be adapted to meet your situation -- it's explicitly defines core principles and practices which you must adopt to claim that you're agile modeling and supplementary principles and practices which you should consider adopting depending on your situation.

- Scott


<a href="http://www-306.ibm.com/software/rational/bios/ambler.html" target="_blank" rel="nofollow">Scott W. Ambler</a><br />Practice Leader Agile Development, IBM Rational<br /> <br />Now available: <a href="http://www.ambysoft.com/books/refactoringDatabases.html" target="_blank" rel="nofollow">Refactoring Databases: Evolutionary Database Design</a>
Ilja Preuss
author
Sheriff

Joined: Jul 11, 2001
Posts: 14112
Originally posted by James Coplien:
"Agile" means the ability to move quickly and to adjust to changes (in requirements, etc.)


Actually that's the dictionary definition for "agile" (see http://www.m-w.com/cgi-bin/dictionary?book=Dictionary&va=agile ) - "Agile Software Development" is a movement that is more specifically described by the Agile Manifesto ( http://agilemanifesto.org/ ).


Many "Agile" methods force the enterprise and its customers to bend to fit the method;


That would of course be totally silly, and I don't know anyone who is advocating doing that.

On the other hand, you can't expect grandiose improvement without changing anything, and often enough it's not only the development team that could use improvement, but also the ways the whole enterprise works, or how you interact with customers. But that's not specific to some methods - if at all, there are just some methods which make this more visible, and give more "drastic" advice in this regard.


XP is one of the highest ceremony methods, and least adaptable methods, there is.


It's true that XP is relatively high on ceremony, in the sense that it has some quite detailed advice on how the team should (start to) work.

But there is more to adaptability than just saying "do what you want". To adapt effectively, you need to know where you need to adapt, and in which direction - and for that you need feedback. The purpose of quite a lot of the XP practices is to provide early and frequent feedback, so I'm far from convinced that XP lacks adaptibility.

It's their way or the highway.


That's simply not true.

Another important part of adapting a method is that you understand how it is supposed to work, and if it isn't working for you wether that is because of your implemention of the method or because of your specific circumstances. That's why the general advice is to execute "vanilla XP" before adapting it. After you get a sufficient understanding of how the practices work and interact, you are actually *supposed* to adapt XP to your needs.

Of course, it hasn't worked out that way: everyone and his brother calls what they do: "XP."


That's not at all specific to XP. People also claim doing RUP and then have "four iterations: one analysis, one design, one implementation, one testing". :roll:

And the XP police aren't interested in chasing down those who claim to follow the Dogma: they are just interested in differentiating themselves from The Heretics.


The last time I looked, there was no XP police - only a community of people interested in sharing their experience about producing software effectively and having fun on the way.


The soul is dyed the color of its thoughts. Think only on those things that are in line with your principles and can bear the light of day. The content of your character is your choice. Day by day, what you do is who you become. Your integrity is your destiny - it is the light that guides your way. - Heraclitus
Ilja Preuss
author
Sheriff

Joined: Jul 11, 2001
Posts: 14112
Originally posted by James Coplien:
XP is one of the highest ceremony methods, and least adaptable methods, there is. It's their way or the highway. [...]

However, the Agile discipline associated with folks like Alistair Cockburn and Jim Highsmith is adaptable.


Interestingly, Jim writes on page 216 f. of "Agile Software Development Ecosystems":


"[...] true improvisation is distinguished by two key properties. First, performers intensely communicate in real time with one another. Second, they rely on a few very specific rules." The authors [Brown and Eisenhardt, 1998] go on to outline common traits of companies with too little, or too much, structure.

[...]

The correct strategy, according to Brown and Eisenhardt, is navigating the edge of chaos - just enough, but not too much. The "improvisational" businesses that manage to do this also have three traits:

[...]
* Semi-structures in which a small set of key structures, such as a small set of generative rules, are never violated
[...]

The point about semi-structures reminds us to be careful when thinking about generative rules. These "rules", wether they are XP's twelve practices or a Scrum meeting's rules, should not be modified without careful thought and experimentation, because careful thought and years of experimentation went into their creation.[...]

[ May 18, 2005: Message edited by: Ilja Preuss ]
Stan James
(instanceof Sidekick)
Ranch Hand

Joined: Jan 29, 2003
Posts: 8791
Of course, it hasn't worked out that way: everyone and his brother calls what they do: "XP."


I'm fairly sympathetic to that opinion. The XP discussion group arguments over "what is XP" surely didn't nail anything down. About the only agreement I saw was "XP is not a thing", whatever that means. I don't even think about "doing XP" any more. I'll pick and choose some practices from all the agile resources that seem to make sense in my culture and not even give the result a name.


A good question is never answered. It is not a bolt to be tightened into place but a seed to be planted and to bear more seed toward the hope of greening the landscape of the idea. John Ciardi
Ilja Preuss
author
Sheriff

Joined: Jul 11, 2001
Posts: 14112
Originally posted by Stan James:
The XP discussion group arguments over "what is XP" surely didn't nail anything down.


Question is: if it had nailed anything down, to what avail?

And as an aside, there are certainly still teams out there we all could agree are *not* "doing XP", even if can't nail down exactly what you need to do to be doing it...
Edwin Keeton
Ranch Hand

Joined: Jul 10, 2002
Posts: 214

Another adaptable approach to the software design process is Feature-Driven Development. (See, A Practical Guide to Feature-Driven Development by Stephen R. Palmer, et al for details.)

Although noted for its upward scalability for larger projects, it is quite adaptable to small projects as well. It's an ordered collection of real-world best practices rather than an "all-or-nothing" approach.


SCJP, SCWCD
Ilja Preuss
author
Sheriff

Joined: Jul 11, 2001
Posts: 14112
Originally posted by Edwin Keeton:
It's an ordered collection of real-world best practices rather than an "all-or-nothing" approach.


Is there any method that's an "all-or-nothing" approach out there?
Stan James
(instanceof Sidekick)
Ranch Hand

Joined: Jan 29, 2003
Posts: 8791
Kent Beck has certainly said some things that sounded like "all or nothing" in the past. A few years ago I thought it was clear that if you're not doing all the practices then "it isn't XP". I don't think he sounds like that any more, and of course some people flame him for changing. I really ought to get XP.XPE2E
[ May 20, 2005: Message edited by: Stan James ]
Ilja Preuss
author
Sheriff

Joined: Jul 11, 2001
Posts: 14112
Originally posted by Stan James:
Kent Beck has certainly said some things that sounded like "all or nothing" in the past. A few years ago I thought it was clear that if you're not doing all the practices then "it isn't XP". I don't think he sounds like that any more, and of course some people flame him for changing. I really ought to get XP.XPE2E


I guess you have the first edition? At the end of chapter 23, Kent Beck writes (sorry, I only have the german translation, so the following is just a rough personal translation back to english):


Does that mean that you must either do all or nothing of XP? Do you need to apply the practices exactly as written, or else risk to not get any advantages? Not at all. Single elements of XP can bring significant advantages. I just believe that you can gain much more if you put all the things together.


One of the very first introductory pages on XP includes the following advice: http://www.extremeprogramming.org/rules/fixit.html

And then there is an excerpt from an email conversation between Kent Beck, Alistair Cockburn and Ron Jeffries (from 1997 as far as I can tell): http://www.xprogramming.com/Practices/justrule.htm

I can understand that some of the discussions on the public forums might have given the impression that XP is an "all or nothing" approach, that it is a "dogma", though.

I think that there are a couple of reasons for this:

* A practice really *doesn't* stand alone, ever. It interacts with other practices, aids or inhibits them, and that often in non-obvious ways. This makes it hard to find a well balanced combination, or change a combination without severely crippling it. I don't think that this is specific to XP, though one of XPs strengths probably is that it actively makes use of the synergetic effects, and therefore consequently might be more vulnerable to changes, too.

* The culture of the XP community includes (in my eyes) not to accept suboptimal processes, but to push improvement as far as possible, and possibly a little bit further. That is, if someone said "I can't do X", the first reply wouldn't be "then do Y", but "why can't you do X? Are you sure you can't? What would need to happen so that you could?" I think that's a rather valuable attitude, but I see that it also could be seen as annoying and inflexible.

* In the early days of XP, people often would claim that "XP failed" for them, but when you inquired, they'd admit that they didn't do "full XP" - "we didn't do Testing, Refactoring or Pair Programming, but what we *did* do is No Documentation". I think it's a valid attitude to say "if you don't follow our advice, don't blame us for your failures", but it also often was perceived as dogmatism.

* The effect even of a single practice can be non-obvious. I'm closely observing the XP community for a decade now, and privatly already used many of the practices, so I think I'm quite aware of what a practice is supposed to do, and how it is supposed to be executed. And still, every time we manage to introduce a new practice into our daily work of the team, I'm almost always surprised on the actual effect. So I think it's fair to say that it's impossible to fully assess the applicability of a practice before having tried it for some time.

* Some people got really great results from XP (compared to what they did before) and got quite excited about it. It's not unlikely that in consequence they got a little bit overboard with their advices. I don't think that this is specific to XP either, though.

* Probably some more I forgot.
Peter Braun
Ranch Hand

Joined: Feb 09, 2005
Posts: 57
As I can see there are so many popular processes. Agile method, Adaptable method, Test Driven Development, Model Driven Development, Feature-Driven Development, XP ...

I would have read tons of books to see through their advantages and difference amongst them. Are these above-mentioned methods used in commercial projects? I only know RUP in details and I have read some articles on MDA.
James Coplien
author
Greenhorn

Joined: Oct 26, 2004
Posts: 22
Originally posted by Ilja Preuss:

quote:
Many "Agile" methods force the enterprise and its customers to bend to fit the method;


That would of course be totally silly, and I don't know anyone who is advocating doing that.
.


I have personally heard Kent say (in English) that unless you were following all of the practices, and all of the principles, you could not call yourself XP. It is a very high-context, high-ceremony, and exclusionary method.

Maybe he's changed. A number of us have been working on the XP community since its formulative days to get a grip on the broader reality of software development.

FWIW, I have not heard Kent say that everything must be XP -- and that is the gist of the quote at the end of the book. However, the quote from the very end of the book is a footnote and should not be interpreted as typifying the dogma or behavior of this "community."
James Coplien
author
Greenhorn

Joined: Oct 26, 2004
Posts: 22
Originally posted by Ilja Preuss:

Question is: if it had nailed anything down, to what avail?


Well, if you have a method associated with your name, nailing it down sure is good for business.
Ilja Preuss
author
Sheriff

Joined: Jul 11, 2001
Posts: 14112
Originally posted by James Coplien:


Well, if you have a method associated with your name, nailing it down sure is good for business.


My impression was that the people participating in the discussion had different goals from that. Might explain the outcome.

On the other hand I suspect that being known for actually being helpful might be even better for business, and perhaps even contrary to nailing the used method down.
Ilja Preuss
author
Sheriff

Joined: Jul 11, 2001
Posts: 14112
Originally posted by Peter Braun:
I would have read tons of books to see through their advantages and difference amongst them.


For an overview over Agile methods, I'd recommend "Agile Software Development Ecosystems" by Jim Highsmith.

I've also heard good things about "Balancing Agility and Discipline", but haven't read it yet (shame on me...).


Are these above-mentioned methods used in commercial projects?


Yes, of course! They are basically the condensation of the experience of people working on commercial projects.
Ilja Preuss
author
Sheriff

Joined: Jul 11, 2001
Posts: 14112
Originally posted by James Coplien:


Nice to see that you are still listening, by the way!


I have personally heard Kent say (in English) that unless you were following all of the practices, and all of the principles, you could not call yourself XP.


I can believe that. It would be interesting to know in which context he said that, though. As I tried to say above, there are a bunch of reasons why (especially in the early days), the XP community was quite skeptical of teams calling themselfs XP teams if they didn't follow all the practices at least for some time.


It is a very high-context, high-ceremony, and exclusionary method.


And as I also said above, I don't see how this, or low adaptibility, follows.


Maybe he's changed. A number of us have been working on the XP community since its formulative days to get a grip on the broader reality of software development.


As I think we all change, all the time, that certainly includes Kent Beck and our understanding of XP.

My impression, though, is that the most valuable advancements in XP came from the people who had real life experience with as close to "pure" XP as possible, and *then* set out to adapt it to a part of the "broader reality of software development".

FWIW, I have not heard Kent say that everything must be XP -- and that is the gist of the quote at the end of the book.


So how does that affect XP's adaptibility? Is it important that Kent Beck allows you to call the adaption "XP", too?

However, the quote from the very end of the book is a footnote and should not be interpreted as typifying the dogma or behavior of this "community."


I'm not sure why you put "community" in quotes here. Some of your tone comes across rather arrogant to me, but I will assume that you intented something different.

Anyway, again the question is, how does the "dogma or behavior of the community" affect the adaptibility of what you call the method XP?

By the way, I just remembered another reason for why the early XP might have been observed as being more exclusive - it's part of the natural way of learning things: http://c2.com/cgi/wiki?ThreeLevelsOfAudience
kaffo lekan
Ranch Hand

Joined: Feb 13, 2001
Posts: 42
Hello, I need to know about the software development methods.

Please help out.
 
I agree. Here's the link: http://aspose.com/file-tools
 
subject: Popularity of software desing methods