• Post Reply
  • Bookmark Topic Watch Topic
  • New Topic

Popularity of software desing methods

 
Peter Braun
Ranch Hand
Posts: 57
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
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
Posts: 1934
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
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.
 
James Coplien
author
Greenhorn
Posts: 22
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
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.
 
Peter Braun
Ranch Hand
Posts: 57
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
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
Posts: 22
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
"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
Posts: 608
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
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
 
Ilja Preuss
author
Sheriff
Posts: 14112
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
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.
 
Ilja Preuss
author
Sheriff
Posts: 14112
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
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
Posts: 8791
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
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.
 
Ilja Preuss
author
Sheriff
Posts: 14112
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
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
Posts: 214
IntelliJ IDE Java Ubuntu
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
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.
 
Ilja Preuss
author
Sheriff
Posts: 14112
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
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
Posts: 8791
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
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
Posts: 14112
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
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
Posts: 57
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
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
Posts: 22
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
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
Posts: 22
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
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
Posts: 14112
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
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
Posts: 14112
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
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
Posts: 14112
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
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
Posts: 42
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
Hello, I need to know about the software development methods.

Please help out.
 
  • Post Reply
  • Bookmark Topic Watch Topic
  • New Topic