Xp Concepts In Accepted Methodologies

KentBeck says in the beginning of ExtremeProgrammingExplained: [...] none of the ideas in XP are new. Most are as old as programming. There is a sense in which XP is conservative -- all its techniques have been proven [...]

See also CreditableMethodologies

Take a look at the 20th anniversary edition of TheMythicalManMonth by Frederick P. Brooks, Jr.

Chapter 16, "No Silver Bullet", was published in way back in 1986 yet there are so many things said in that paper that make you think of XP.

On incremental development:

One always has, at every stage in the process, a working system. I find that teams can *grow* much more complex entities in four months that they can *build*.

On iterative development:

... it is necessary to allow for an extensive iteration between the client and the designer as part of the system definition ... Therefore, one of the most promising of the current technological efforts, and one which attacks the essence, ... is the development of approaches and tools for rapid prototyping of systems as part of the iterative specification of requirements.

In CodeComplete, towards the beginning of the chapter on integration, SteveMcConnell says the following:

[A previous] chapter mentioned that it was unfortunate that no one has ever written a book about incremental approaches to software development because it would be a potent collection of techniques.

"Change is a fact of life with every program. ... even during development of the first version of a program, you'll add unanticipated features that require changes. Error corrections also introduce changes. Develop the program so that likely changes can be accommodated without an act of Congress." -- SteveMcConnell, CodeComplete

"Hiding the areas in which you anticipate changes is one of the most powerful techniques for minimizing the impact of changes." -- SteveMcConnell, CodeComplete

"Evolutionary delivery is an approach that delivers your system in stages. You can build a little, get a little feedback from your users, adjust your design a little, make a few changes, and build a little more. The key is using short development cycles so that you can respond to your users quickly." -- SteveMcConnell, CodeComplete

"This does not imply that mine is the only way to do it (many roads lead to the same destination), but when a lost motorist needs directions to an unfamiliar town it doesn't help much to say there are lots of ways to get there. This book presents one route to Application City, and as you learn to identify the landmarks, you can decide for yourself when and where to safely take shortcuts." -- Thomas Leylan, Writing Applications with Clipper, 1994 M&T Books, ISBN 1-55851-382-5

I lost the wiki page on which it was stated that SteveMcConnell asserted that private offices are more effective than shared. If you find that page, you can merge this comment with that. I followed the link on that page and found the following relevant sentence:

A handful of software research studies have found that productivity of developers who work in private, quiet, one- or two-person offices can be as much as 2.5 times as great as the productivity levels of developers who work in open work bays or cubicles.

Note carefully that he includes 2-person offices... the claim is not that a single office is better than a shared office. In fact, I'd like to know what the real claim is. cheers, -- AlistairCockburn

Surely the emphasis here should be on quiet offices rather than an understanding of PairProgramming. Privacy means isolation. Open offices provide signal plus lots of noise. I think the optimum is the small team office for developers and another office grouping project managers.

<g> Not everyone would consider the Bible an accepted methodolgy, I suppose:

''Two are better than one because they have a good return for their labor. For if either of them falls, the one will lift up his companion. But woe to the one who falls when there is not another to lift him up.'' [Eccl 4:9-10]

Prov 15:22 NIV) Plans fail for lack of counsel, but with many advisers they succeed. [The importance of feedback...]

There is a story told of (I think) Lord Louis Mountbatten in India. Inquiring of two men digging, one pushing the shovel in and the other pulling it up with a rope, he was told it was "a device to enable two men to do the work of one".

That doesn't seem to support the point of this page... - ChrisMorris

Take a look at http://www.dsdm.org/tour/principles.asp. I'd be interested in seeing a comparison of XP with DSDM (see DynamicSystemsDevelopmentMethod). I'm surprised a comparison hasn't been made yet. -- StuartBarker

See CompareDsdmAndXp

CategoryAdoptingXp

EditText of this page (last edited January 10, 2005)
FindPage by browsing or searching

This page mirrored in ExtremeProgrammingRoadmap as of April 29, 2006