All we need is more managers thinking we can start coding before we know what the client wants. I've seen too many projects fail this way.

"...their strong individual oppinions about how software should be developed..."

That's part of the problem, not a solution! When engineers are designing an aircraft, is collaboration shunned because of strong individual opinions? How about doctors in surgery?

Strong egos are a problem, not a benefit. I believe that it was Steve Maguire *from Microsoft* who wrote that if you have star programmers, get rid of them. The team is much more important than any of the individuals.

Notice that none of my comments here have anything specific to do with XP!

Interesting to note that, although Microsoft practices some elements of agile development in their software development process, they have almost universally shunned "pair programming." I once asked one of their most succesful PM's why this was the case (this guy has over 1000 developers reporting to him -- so he is no light weight). He said that, based on the high caliber of the people that they hire, he had no doubt that their strong individual oppinions about how software should be developed would lead to a murder within the first week if they ever insisted on universal pair programming. :-)

So, they use code reviews, instead.

Some closing thoughts on this discussion (at least for now):

1) I think the truth of all methodologies/processes is that ther will always be many to choose from, so my advice for any company is to choose one that appears to suit you best, and then fully implement so that everyone uses it,and use it to deliver results for the forseeable future, until its effectiveness declines. I have always felt that one of the major benefits of a common methodology is eveyone speaks the same language, and can communicate using the same techniques/tools.The worst thing is to change methodologies every year or two to follow the pack, because you will never get all the benefits from the methodology you are already using.

2) I think it is, in hindsight, too bad that XP has the word 'Programming' in its name, because it makes some people think that all you do is, well, program!

3) By coincidence, I was looking through a recent Dilbert book and found a page of strips on XP; I will not make a feeble attempt to communicate the humour, but the words 'requirements' and 'user stories' were used.

So, to each their own, as long as it's workin for ya' (loose use of a Doctor Phil quote...)

"to think that we should interatevely program is nonsense"

Read this...

http://www2.umassd.edu/SWPI/xp/articles/r6047.pdf

We've been doing iterative, incremental development since the late '50's. Winston Royce, the 'father' of waterfall even suggested developing the core parts of an application twice. Barry Boehm created the spiral development model, which is iterative. IBM/Rational has RUP, which is iterative.

Nonsense indeed.

"It is highly indicative of the success of XP that the first project by Mr. Beck failed"

Not because the system was late, full of defects or didn't meet the business requirements. In the time since XP Explained was published in 1999, how many projects using traditional processes have failed? How many have been full of defects or didn't meet the customer's requirements?

More nonsense.

"my first impression"
"to think that we should interatevely program is nonsense"

I suggest you take your knowledge of XP past first impressions based on what looks like no first hand experience and very little research.

"It is highly indicative of the success of XP that the first project by Mr. Beck failed"

I haven't read a lot on the failure, but from what I have, that statement seems simplistic. Have you read anything about the project or are you doing so in a selective manner or is it that sweeping statements better suit your position? And of course every successful idea suffered no initial failures...

While Kent's aims are to deliver software accurately and quickly, my first impression is (as a manager of many projects) that of excuses given to me by developers for not providing the proper design documentation. I think that the discovery of requirements process could be enhanced by writing tests to descrime the requirement. However, to think that we should interatevely program is nonsense; we certainly could iteratively design as we discover requirements through use cases.
It is highly indicative of the success of XP that the first project by Mr. Beck failed.
Thanks

"You have to have an architecture that lets you deliver manageable portions or components at regular intervals."

THAT is the purpose of XP. Whether you use the entire XP methodology or not, if you diliver managable software components at regular intervals, you are following the spirit of eXtreme Programming.

"The build button", yes, compilers, as we knew them when I was a programmer....UML-to-code tools do exist, as the developers at my previous job were using a tool whose name now escapes me, except it started with "J"... Jsoft? I don't think that's it...but anyway, I was doing conceptual models and business use cases in Rational Rose for Requirements, and the developers would then then use this J tool to create Class Diagrams and other UML design artifacts, then push the "button" to create the Java code.

Other comments for now: 18 month development projects that don't deliver anything over those 18 months? Is anyone really working on those kinds of projects anymore? Those kinds of projects have been know to fail for many reasons, not just because the business requirements may have changed. You have to have an architecture that lets you deliver manageable portions or components at regular intervals. That way, you can have long projects if that is what is needed to develop a large system, but you don't have to wait to the end to get something the business can use.

what is this build button you speak of? What does it use as an input resource and what gets produced? Is this an alias for code generation? Are you using an IDE to create UML and then generate code, perhaps in Java?

Well, what the build button does exactly depends on your language and the scope of your project. But in short, it is what your build system (such as Ant) does, that is, convert your source code into an executable set of files. What I'm saying that there is no construction phase in software development that requires human intervention. This phase is or can be completely automated. At lower levels, this is done by compilers. At higher levels, this is done by automated build systems (make, ant, etc...).

I admit that I'd like to take the design specification one abstraction level up, and stop at the UML level like you suggest, but unfortunately I haven't come across a tool yet that has a sufficiently flexible code generation engine to do that for anything but the initial phase. The newest breed of tools claiming to support Model Driven Architecture (such as OptimalJ) look very promising, but I've not had the opportunity to check their capacity in this respect.

Regards
-Gudlaugur Egilsson

The distinction between Holmes' "iterative programming" and de Champeaux's "iterative thinking" is in where coding and prototyping fit into the design and development process. XP intentionally builds programming tools into the design process. This allows the users to SEE what the designers heard instead of LISTENING to them parot back their own words. Non-XP methodologies depend on human language and diagrams for the designer to demonstrate understanding. The only way this "iterative programming" is feasable is to strictly adhere to the XP requirement that users must be implementable in under two weeks. The intent is to avoid that old problem of spending 18 months of development time only to have the user say, "That's not what I wanted."

First off, I just want to say this is an enjoyable conversation, and it is great to have a forum like this to allow it.

"Regarding the comment on changing a system by altering business rules in a rules engine: that's just programming by another name. Any substantive change in behaviour needs to be tested before being released to production. The way in which those rules are reified is secondary."
I sense a little theoretical sophistry here. You may call this programming, but it certainly does not require a programmer, in the traditional sense. There are many rule-driven engines out there (some for sale) that support what-if analysis if you change the rules to see the impact, before you implement the rules for use in the production environment; that is testing, but again it is done without the involvement of a traditional 'tester' as well. So, you have to have to have a clearer definition of what programming is in the context of XP; does it require knowing and using a programming language? I think that is what it means, but I would like to hear other opinions.

"And no, coding is not construction. Construction takes place when you hit the "build" button (you know, build == construct). Anything going on until that point is requirements gathering and design (yes, coding is also design). "
Pure curiousity question: what is this build button you speak of? What does it use as an input resource and what gets produced? Is this an alias for code generation? Are you using an IDE to create UML and then generate code, perhaps in Java?
Also, it is true that design has not been given its due in this discussion. If we adhere to the standard statement that Requirements are "what, not how", creating a design to deliver on those requirements is ceratinly the "how, not what". Given this, at what point in XP are test cases written in relation to Design? before or after?
Also, presuming you are using XP to produce an Information System (as opposed to things like games, or missile guidance software...), how does XP define and deliver the data structures needed for the system, as opposed to executable program code?

Cheers for the weekend...DW

RE: de Champeaux's criticism that Holmes' statement, "XP was one of the first development processes that fell into the realm of iterative programming," is rediculous: I think there is a slight distinction between "iterative programming" and "iterative thinking."

Just a point or two:

I don't know who claimed that Kent Beck created iterative thinking, I just know it was not himself. He has said himself that all he did was to take a few known best practices and "turn the knobs to 10". So rambling on this is completely pointless imho.

As to the point: "This is a serious insult to those that have worked for decades to develop software development methods (no not methodologies),". Well, in my view, the track record of the software industry has shown that the thinking underlying traditional methodologies has been in need of a serious challenge for years. It seems that XP the agile development methodology movement has done just that, challenged the traditional methodologies. I is still too early to tell the long term effects, but I'm fairly confident that they'll be positive.

I would also like to point out that a number of the practices promoted by XP really started catching on since its inception. Think for instance about unit testing (JUnit was written by Kent Beck and Erich Gamma). The concept of refactoring also originates from XP circles. And every self-respecting software shop is doing daily builds these days.

And no, coding is not construction. Construction takes place when you hit the "build" button (you know, build == construct). Anything going on until that point is requirements gathering and design (yes, coding is also design).

Regards
-Gudlaugur Egilsson
Software Engineer

I think you'll find that Kent Beck now emphasises testing as being just about the most important part of XP. You are right that programming is a "solution space" activity. But in test driven development one writes the tests first - and these are a "problem space" activity (specification by example).

Regarding the comment on changing a system by altering business rules in a rules engine: that's just programming by another name. Any substantive change in behaviour needs to be tested before being released to production. The way in which those rules are reified is secondary.

If the business changes before the software is delivered, then the ability to accomodate business change IS a requirement. Are you familiar with the Business Rules approach to system development? see www.businessrulesgroup.org... its goal is to deliver systems that be changed as needed without program/software changes.

If that approach is not appropriate --- and I am sure it is not always appropriate --- you can define an overall system architecture/scope, then iterate the detailing of requirements and the subsequent construction of components/releases, which the architecture fits together. You don't have to have all the requirements to begin programming, but you have to have them for the component/release you build next.

Finally, all programmers (and I have been one) should be aware that program code can be generated from Requirements models by many tools. The somewhat lumbering CASE tools circa 1990 almost succeeded, but they fell away as businesses swarmed to Enterprise systems like SAP; its' easier and faster to buy code than to generate it, let alone code by hand... now it is starting to make a comeback, I believe, with the Model-Based development advances I have seen lately. So, delivering systems quickly to the business may soon need no programming at all... and if you don't agree with the impact of code-generation, consider component-based development; once a component is built, you never build it again; system development becomes system assembly.
I have gone on at length about this mainly because extreme programming just seems to fall into line with that old cliche, "If the only tool you have is a hammer, then everything looks like a nail". Some things just need you to use different tools.

"It's the Requirements, stupid!"

Yes...

"Programming is a construction task, it is not a means of discovering solutions, it is a means of delivering them."

...and the time it takes to get the requirements to a state of precision required to make programming just a construction task is too prohibitive.

By the time any software is shipped to the users, the business has already changed. XP is focused on getting the software to the users as soon as possible (through small releases), with the highest quality possible (through rigorous testing), in order to provide the highest business value possible (through story prioritization in the planning process).

I'll take that extreme any day over moderation that delivers obsolete software.

Some thoughts , in no particular order...

I have always preferred moderation over extremism.

It's the Requirements, stupid!

Programming is a construction task, it is not a means of discovering solutions, it is a means of delivering them.