Software Reality
Extreme Programming

Site Map

XP Central
Case Against... Songs

Use Case Driven
Use Case Driven Object Modeling with UML: Theory and Practice
Get from use cases to working, maintainable source code. Examples use Spring Framework, JUnit and Enterprise Architect

Agile UML
Agile Development with ICONIX Process
A practical subset of agile development techniques, illustrated by example

Get Controversial!
Extreme Programming Refactored
Extreme Programming with a dose of satire
Available now:




Extreme Programming

XP Message Forum - Archive, Page 4


Message Index

xp and software architecture
Ramakrishnan V vrk1981@yahoo.com

Re: XP from the Trenches
Greg Weinman Gregory@messerweinman.com

Total lack of insight
Torbjörn Gannholm torbjorn.gannholm@swipnet.se

Good Point
Taylor Cowan

Article comments
Carl Smotricz rup-newbie at smotricz.com

Were you reading the same article?
Greg T.

Terrific!
Marc marcha64@yahoo.com

XP process support
Steven Verhaul Sverhaul@sytec.com

XP working in practice
Keith Braithwaite keith@keithbraithwaite.demon.co.uk

Two kinds of people...
Dave Kirby dkirby@blueyonder.co.uk

re: Two kinds of people...
Matt Stephens

Critique of article page 1 (others to follow)
Keith Braithwaite keith@keithbraithwaite.demon.co.uk

Page 2, practices
Keith Braithwaite

re: Critique of article page 1
Matt Stephens

RE: XP working in practice
Timothy Fisher trfishermi@yahoo.com

Response to Timothy
Keith Braithwaite

12_XP/AgileMethods_Evangelists vs Reliability, Safety,
Security, Integrity, Privacy, or Dependability

H L Hausen hausen@gmd.de

A realistic analysis of an actual implementation
Mike Barnes socscisam@hotmail.com

Research into xp, Your Thoughts
Martin Hayes martin_john_hayes@hotmail.com

Technical Rants That Miss The Point Massively
Matt Morris matt@arkestra.demon.co.uk

re: Technical Rants That Miss The Point Massively
Matt Stephens

Want Suggestions/Views
babatu kimbhutkimakar@yahoo.com

Suggestion for more comment
Ernie Gutierrez egutierrez@ttwireless.com

What if XP isn't right or wrong?
chad chad@cyber-reality.com

re: What if XP isn't right or wrong?
Matt Stephens

is xp realy working for structured engineering?
tshepo mchapa@webmail.co.za

XP Testing Without XP
editor

XP Article.
Paul Wolfowitz pwolf@yahoo.com

Creativity and Flow
anon

Why process?
Jason Craven jcraven@1three.com

Peer programming
Robin Sharp robin.sharp@javelinsoft.com

No plan = doom
Fred

customer doesn't have to be a...customer...
michael

To XP or Not
Lionell K. Griffith griffith@syv.com

the new methodolgies, pick your side and join in your very own holy war!
Mark Angrish this_is_not_a_stop_sign at hotmail dot com

The problem is really the "extreme" part
Moraelin n/a

manager's view of XP, one year of using it
ron zart@myway.com

Then IMHO it's not XP
Moraelin

How could anybody be against XP?
David Mace evildave@sti.net

RUP & XP
tony yayo

General comments
David F nospam@nospam.com

review of XP Refactored
Jeff Langr JLangr@Yahoo.com

re: review of XP Refactored
Matt Stephens

re: XP refactored review
Jeff Langr JLangr@Yahoo.com

Wired Article
Arthur Bitter ferocious.beast@nowhereland.com

review of XP Refactored
Jeff Langr Jeff.Langr@LangrSoft.com

XP not extreme enough
John jgraley@rioaudio.com

Team composition
David Gerrard dave@dgcv.co.uk

Does XP really solved any problem?
xpandy hsesual@yahoo.com

I would like to know how might Extreme Programming be adapted to handle the inte ...
Vianca vianca@hotmail.com

Matt Stephens - Pair "Authoring"
DCarlson carlsods@tvratings.com

re: Matt Stephens - Pair "Authoring"
Matt Stephens

I have undone thee!!!
Dino Fancellu

Is there a site like this for debunking the linux hype?
I4get

Manager QA Extreme Programming/Testing needed
Larry Zeichner eXT@uscareers.com

I actually wasted time reading this !!
Kevin J Citron kjc5664@yahoo.com

I agree... you do need documentation, design, prototyping first
Leo Jacob

my 2 cents
c. colombo

Poor Design
Darren

Going round and round and getting nowhere eXtremely fast?
Anonymous person



The Messages

xp and software architecture
hai,

I know little about XP. As far as i have read about XP i never find any notion of " Software Architecture" in XP. Is that true?

Is lack of "sofware Architecture" a Boon or Bane to XP?

Thanks a lot for your time.

Ramakrishnan V

Ramakrishnan V vrk1981@yahoo.com
TX, usa

Wed Nov 20 01:26:01 GMT 2002
Re: XP from the Trenches
Reading the article "XP from the Trenched" leads one to believe management has lost control in that shop. Business is not democratic. Any business that chooses to let programming staff direct the project will see dismal results no matter the methodology.

As to the points raised:

Every successful project requires a stakeholder. This person or committee is the on-site customer. The stakeholder sets project direction and accepts project deliverables. In my 25 years of information technology I have seen what happens to projects without a stakeholder. None have made budget and none were delivered on time.

Pair programming is not sitting the fastest typist at the terminal while someone looks over their shoulder. Pair programming stems from the adage that two heads are better than one. Every time I've collaborated on program design I've gained insight into either my own design or my collaborator's design. This is because one must gain a deeper understanding of something in order to explain it to another.

The KISS principle is based on Occam's Razor. Remembering always that KISS != HACK, a programmer can be guided to a best solution by keeping the principle in mind, discussing the problem, and developing with XP ethos. In this, pair programming really shines. I'll bet the article's author has discovered simpler methods simply by discussing problems with his/her peers.

The statement that project decisions are made code-centric without considering the project's scope highlights the lack of a stakeholder and the lack of management understanding. I would be surprised to see any project of substance make scope on time and within budget when this is the case. More's the pity that someone equates shoddy project management to XP principles.

Greg Weinman Gregory@messerweinman.com
Belmont, CA, USA

Mon Dec 16 18:32:09 GMT 2002
Total lack of insight
I hoped to find some valuable insights in your article "The Case against Extreme Programming", but sadly it was a waste of time. Instead of intelligent insights you manage to demonstrate a total misunderstanding of XP.

Examples:
-Testing
"The basic premise is that the test class is written before the real class: thus, the end purpose of the real class is not to fulfill a requirement, but simply to pass all the tests that are in the test class."

What are the tests, if not a representation of the requirements?

Yes, you do get twice as much code, but anyone who has tried it knows that you go ahead faster and with more confidence and produce an order of magnitude fewer bugs.

-Requirements
"Could you knock together a Java applet for us to display on our website? Yeah, it just needs to do stuff."

Do you seriously propose that that is how XP works? Firstly, the "requirement" of "Java applet" would never be accepted. Secondly, the customer has a business need, so it would more be like "We want to display order info to our customers on the web". The customer says "what", together we work out "how" and also work out "exactly what" during the development process by asking the customer for more details.

XP is about helping a customer with what he needs, rather than with what his requirements are. If an XP team thinks that pencil and paper better serves the customer's need than an IT-system would, they say so.

-Pair programming
Studies have shown that pair programming produces more robust code faster than programmers working alone. Check one of the XP sites for links. One of the points about pair programming is that the code produced is such that both the novice and the expert understand it, as will the future maintenance programmer.

-Refactoring
Refactoring in XP is done basically for two purposes:
1) To make the code easier to understand
2) To make it easier to add the new requirement you are currently working on
Anyone who has tried it knows it saves time (don't do too much of it without tests, though). Read Martin Fowler's book some time.

-Design
There is up-front design in XP. It is called the metaphor. Then the details are designed day-by-day, concentrating on the simplest thing possible. Practically it works very well, no matter how much you don't understand it.


I won't waste more time on this.
XP is a mindset, not a methodology, no XP:er wants to call it a methodology. I guess you either appreciate the XP mindset or you don't.

Personally, the XP way makes it more fun to work and gives more satisfaction because I feel it solves customer needs faster and at lower cost than any other way of working. XP is perfect for an inhouse IT-department, which is where I have preferred to work.

Torbjörn Gannholm torbjorn.gannholm@swipnet.se
Luleå, Sweden

Fri Dec 27 13:56:54 GMT 2002
Good Point
>XP is a mindset, not a methodology, no XP:er >wants to call it a methodology. I guess you >either appreciate the XP mindset or you don't.

What a great point! Well said. I think this sums it up very well. So you're saying it's just a state of mind like being happy, blissful, or perhaps high?

Taylor

Taylor Cowan
Texas

Fri Dec 27 23:14:23 GMT 2002
Article comments
Intro and disclaimer: While I'm a seasoned consultant/analyst/developer with about 20 years of experience, I'm mostly new to "Methodologies" as such. In plain English, I don't claim to know a lot about this stuff, but I do claim to be a reasonably open-minded citizen of the Net.

I've read Beck and I've read Kruchten. I can conceive a number of scenarios where I think XP would fail, and I can envision projects marching to their death while carrying the RUP banner. I don't believe in the tooth fairy and silver bullets. I'm just looking to get a "taste" of various attempts to slay the dragon of doom.

My company's management has ruled that THERE SHALL BE RUP, and so as to be able to participate intelligently in the process and discussions about it, I'm spending my X-mas/New Years vacation browsing around sites dealing with RUP, XP, UML and related themes.

With all due respect for Mr. Stephens, I was appalled at the tone and quality of his piece,
"The Case Against Extreme Programming". "Lively and humorous," indeed! The material on this site, and the article in particular, come as close as anything I've seen in the past year to being classified as "hate pages." If, as others claim, Mr. Stephens is a jolly and pleasurable fellow, then at least his vitriolic comments make him out to be a jolly and pleasurable fellow with a serious axe to grind. Did Beck steal his marbles when they were both kids or something?

Like "most programmers," I take exception to being called stupid. Maybe I am, but I didn't come here to have Mr. Stephens tell me so. I came here for useful information on software development methods. Instead, I have found here a tirade of bitching and moaning backed by a distorted misrepresentation of what appears to be Mr. Stephens' warped impression of XP.

To not grow tedious, I'll just cite a couple of examples of his artless bashing as encountered in his takes on refactoring and pair programming:

He states that XP programmers are "constantly refactoring their code", and makes it sound like it's done for the hell of it. As I understand it, refactoring is most commonly done when two pieces of code are newly interfaced, or some pre-existing code is changed to meet with changed requirements, and this process brings to light opportunities for simplification or improvement. I'm convinced that this is a healthy process, as better, cleaner code is easier to maintain. "A stitch in time saves nine" and all that. Stephens makes it sound dirty, like something not done in polite company. It's none of my business, but let's assume for the sake of metaphor that Mr. Stephens is happily married. Would it be in good taste for me to phrase that as, "he's constantly having sex with that woman he's living with?"

On to a related activity, pair programming. Mr Stephens, intentionally or not, mistakenly equates pair programming with marriage "till death do us part." He summons the spectre of "I couldn't work all day because my pair called in sick" but conveniently fails to consider that pair programming is considered by XP to be a dynamic and fluid (polygamous?) process, with explicit provisions for changing partners and roles, possibly several times a day! He claims that his mythical "most programmers" have severe ego problems that prevent them from working in a pair. I'm tempted to think that he is generalizing from his own case. If I'm not like "most programmers", there's hope I may not be stupid either; my mileage definitely varies.

I have performed heroically, both in quantity and quality, on solo marathons. But I take pride in being a good consultant, a good mentor and a good learner. I've had the pleasure of teaching my favorite tricks to clever newcomers, I had the patience to enlighten some not-so-bright colleagues without bemoaning the time I could have spent writing the Great American Program, and I have been honored to co-code with our company's most brilliant. I have worked together with my peers, often for hours or days, and we crafted code neither of us could have produced on our own. Some problems lose their complexity in a pair, and the experience is exhilerating when it happens. What a shame that Mr. Stephens' ego and/or preconceptions prevent him from knowing this experience, which he likens to sticking his head in a bucket of shit.

The impression I took away from the article was that either Mr. Stephens knows even less about XP than I do, or he is intentionally misrepresenting it because belittlement is his only way to counter possibly threatening competition. Perhaps my impression is wrong, but then this is not my fault but his. I would advise him to attune his communication skills more toward the higher end of what one experiences on the Net, to learn to express himself like a human being one would look forward to meeting in person.


Carl Smotricz rup-newbie at smotricz.com
Frankfurt, Germany

Wed Jan 01 18:58:09 GMT 2003
Were you reading the same article?
You refer to "the mythical 'most programmers'."

I couldn't find a single place in the whole article that says "most programmers".

Also, Mr Stephens does not liken pair programming to "sticking his head in a bucket of shit". He's saying that he wouldn't need to try it to know he wouldn't like it. Besides, he's talking about CONSTANT pair programming. The article states that he sometimes pair programs and has found it useful. You seem to have conveniently ignored that in your response.

Where does he equate pair programming with marriage "til death do us part"?

Where does he say that "most programmers have ego problems"? Answer: he doesn't.

In fact your response seems mostly concerned with attacking his supposed character. "It's none of my business, but let's conjecture about his private life anyway..."

Rule number one of XP: shoot the messenger. That is, attack the person's character instead of what he is saying. Welcome to XP: you will fit in well.

Greg T.
UK

Wed Jan 01 21:15:03 GMT 2003
Terrific!
It recalls me the fake article written by Stroustroup pretending C++ was a merelly invention to increase programmers salaries.
Or in another style the famous how to write unmaintenable code with its unbeatable "testing is for cowards".
But this time the satire is really a harsh one I have to admit that I could not articulate and answer until I read others people one's. If you adere to Matts points you automatically range yourself among the superior intellectual class that does known the true,if you don't then you are declaring yourself as a novice that does Xp because it's fashionable and because you simple don't know better.
As is it a destructive work it is hard to strike at it there's nothing said in positive you are forced to entrench and drived by the all or nothing nature of XP to sumarize to whole with a yes or no.
On the other hand it does a very good jobs to XP programers outlining almost every perversion that imbecility can bring to method this is a very valuable service.

Ivar Jackobson asked himself why making software was so much dificult that to build a brige and the answer was: just because we have 10.000 years brige experience...

Quickly IT is becoming essential part of almost any bussines and thus the gap between bussines and IT decreasses at the same rate,at the end sales will be seen as just output parts of the IT process so I thing that more and more both points of view bussines and IT will become indivisible, and the remining open question will be about general management.

Again maturity is the main problem,even mature teams with many succesful project might fall under the weight of a new paradigm, the entanglement between bussines and IT puts the pressure in IT as by now bussines changes are expresed in terms of IT new neds ,becoming thus natural the need for perpetual improvement on software, not for the nature of method or software but of bussines.As on the other sofware paradigms are not settled at all each of this changes carries inmense potential perils as much as oportunities.The fact is that admittedly or not we are still at the cambric ages of the evolution when biologist tells us "life was experimenting itself with countless models in an attempt to find something endurable unther the sun"

Very nice reading indeed!!

Marc marcha64@yahoo.com
Barcelona, Spain

Sat Jan 18 13:23:54 GMT 2003
XP process support
Hi all,

We are trying to do Xp for a year now, with good and bad experiences. But the reason I am posting this, is because we found a Xp process management tool on the web some months ago: www.scopemanager.com. Do any of you guys ever used it.

We started using it a couple of weeks ago, and it actually works super! So try it, and tell me what you think.

Steven Verhaul Sverhaul@sytec.com
San Fr, US

Tue Jan 28 09:39:12 GMT 2003
XP working in practice
Maybe I'll come to regret doing this, but I feel that I must respond to the content on this forum.

It seems that almost every week I come across a new (to me) article explaining how XP:
1) can't work in theory
2) doesn't work in practice
3) couldn't even be fixed up to make it work

There seems to be plenty of those sentiments expressed here. But I can't understand why.

I've been using XP techniques (to a greater or lesser extent) to run development projects for about four years now. I've also done research into XP in principle and practice, and have delivered XP training and consultancy. I find, and my clients, find that XP works very nicely.

For the last couple of years I've worked in a team that uses XP exclusively. In that time we have produced no Gantt or PERT charts, we've done all of our project planning and tracking with story and task cards.

In that time, we have prepared not one comprehensive requirements, analysis or design document. We capture requirements using a range of techniques, from the occasional use-case, to emails, to hand-written notes, to memory. We think about design using UML diagrams sketched on whiteboards, and with CRC cards, and we capture these design ideas in tests.

Every line of code that we release to a customer was written by two developers working collaboratively together. Most of them will have been written as the result of a failing test. The design of them will have been continually improved through the use of refactoring.

We integrate at least once a day, and a ready-to-ship release gets built automatically overnight. Every night.

We work no overtime. Ever.

We've applied these ideas to: re-implementing Java for a new platform, porting a proprietary messaging technology, implementing novel text entry technologies, building applications for consumer and industrial hand-helds, producing self-study and training materials, writing both ends of client-server and web-services systems.

Our clients are delighted with the way that our working practices lead to on-time, to-budget and high-quality deliveries. Consistently.

Our estimating and planning (all done with cards, recall) is uncannily accurate, allowing us to commit and to meet our commitments. They like that too. They like the way that we mange change (rather than controlling it). They offer us more work than we can take on, they like what we do so much.

There's nothing special about us. Team members' experience varies from months to decades. Few have had prior experience of XP before joining us. We pretty much read the book, and then did what it says. And it worked for us.

Keith Braithwaite

Keith Braithwaite keith@keithbraithwaite.demon.co.uk
UK

Thu Feb 06 20:50:02 GMT 2003
Two kinds of people...
I have noticed that the debate about XP is invariably conducted between two types of people:

* those who will never do XP because they know it can never work, and
* those who know it does work because they have done it.

The numerous generalisations, distortions and deletions in the article reminded me of this:

http://www.netfunny.com/rhf/jokes/93q1/revbomb.html


Dave Kirby dkirby@blueyonder.co.uk
London, UK

Thu Feb 06 22:52:31 GMT 2003
re: Two kinds of people...
Dave,

Thanks for the comments. Could you let me know which parts of the article you felt to be generalisations, distortions or deletions?

I do update the article based on peoples' feedback, so your comments are welcome.

Thanks,

Matt Stephens
UK

Thu Feb 06 23:28:05 GMT 2003
Critique of article page 1 (others to follow)
Everything that's claimed in page one of the article is either obviously true, or clearly highly probable. Unfortunately, it tells us next to nothing about XP. Below, I've taken almost the whole text and substituted generic terms for XP specifics. Take a moment to read it.

----

As [methodology] increases in popularity and hits the mainstream, more and more teams will attempt [methodology], probably without a clear understanding of what is really involved.

They will most likely be drawn in by [methodology]'s [promised advantage], but without applying the [discipline] that [is required to obtain that promise]

In fact, I observed one [methodology] project in which the management had warmed to [methodology] because they saw [outcome] as a way of saving money. However, they refused to allow the team to perform [mandatory practice1] on the morass of badly formed code that emerged, because they felt that now the code was written, spending more time on it would be a waste of money.

The programmers also [botched the job] because they hated to [mandatory practice2]. The result was [a mess]

Of course, this project could not be described as "real" [methodology] project because they were not following all the practices. However, it's a good indication of what happens when [methodology] hits the mainstream software development world.

Not everyone out there is an [methodology] process expert. Not everyone has time to read all 20 [methodology] books, scour the [methodology] newsgroups for vital information not contained in the 20 books, and so on. Not every team will have access to an [methodology] Coach (either full or part-time).

In other words, the amount of hype that surrounds [methodology] is not matched by the requisite skill-set needed to succesfully execute an [methodology] project. I suspect that the result (as [methodology]'s promises entice more and more teams) will inevitably be confusion, and a dirty underbelly of (mostly unreported) failed attempts at [methodology].

----

The question is, for what value of [methodology] etc. would any of this not be true? There already is a dirty underbelly of (mostly unreported) failed attempts at RUP, for instance. RUP is hard to do right: it requires management support, investment in the team and developer buy-in. Without those things it will, and does, fail. The failure modes are different, of course: RUP-type projects fail by slowing to stop, XP-type projects fail by racing out of control.

Is either more or less likely to fail within its domain of applicability than the other? I don't know, the studies that would answer that question aren't being done. Having worked on (alleged) RUP projects, and (alleged) XP projects, I know which I believe offers the best chance of successful delivery, but that's just my experience.

I also know that many, many successful RUP projects exist in the world. I wouldn't particularly want to work even on a successful RUP project, it's a style of development not to my taste, but it doesn't bother me that other folks would.

I wonder, what is your experience of working on XP projects? How many XP projects have you worked upon? For what duration? I ask, because the very few points you make that are specific to XP seem to be based upon your "observing" one project only. And yet you are claiming to make generalisations about XP in all cases, for instance that "[the one project you observed is] a good indication of what happens when XP hits the mainstream software development world." How do you justify that generalisation?

Keith


Keith Braithwaite keith@keithbraithwaite.demon.co.uk
UK

Fri Feb 07 22:15:03 GMT 2003
Page 2, practices
The one-dimensional chain of practices described in the second page is an effective rhetorical device, but it does not correspond closely to the recognised collection of XP practices, nor to the recognised network of mutual support between them.

Its interesting to note that amongst the very earliest criticisms of XP was the frequent complaint that there was nothing to it, that the practices were merely what "good developers" have always done. Now, a few years later, the claim is often made that the practices are unsustainable.

Well, the article mentions six practices, only four of which (pair-programming, unit testing, constant refactoring, on-site customer) correspond to any one of the twelve "canonical" XP practices.

Let's consider the other two first.

"No detailed written requirements". Most XP teams do have some written requirements, and they are usually fairly detailed. What they typically are not is: comprehensive, formal, subject to change control procedures. Perhaps you've made the mistake (common to XP neophites, as well as nay-sayers), of confusing story cards with a requirements documents. Story cards are placeholders for conversations about a part of the requirement. A given requirement itself can be captured in a range of forms, sometimes even including formal documents.

"No big up-front design" While this is not one of the twelve practices, it is a common phrase amongst XP developers. And it means what it says, that is, no design beyond what is needed, when it is needed. It emphatically does not mean no design.

It's interesting that you should begin your criticism of the practices with these two non-practices, since what you have not mentioned is the actual practice of the "planning game". During the planning game (which can take a substantial amount of time) many conversations go on about the requirement, many design ideas are formulated and exercised by prototyping techniques. All before the schedule for the project is drawn up, and before production coding begins. XP projects typically do not "leap underway" without ANY formalised requirements, nor without a "solid idea" of where they are going to end up, as you claim Quite the contrary. What XP projects do recognise, is that in the vast majority of commercial development projects the requirement (formal or otherwise), and therefore where the project is going to end up will change.

One XP project that I've worked on came to a successful conclusion with one fifth the total requirement never examined, and around a third of the requirement discovered only late in the project. I believe that this result is typical, and supports the view that early, "comprehensive" analysis activities inevitably involve a significant amount of wasted effort.

Your comments on refactoring and unit testing I simply cannot understand, so far removed are they from my experience of those two techniques. What you write is not even a caricature. The canonical practice, by the way, is Tesing, which includes both unit and acceptance (functional) tests.

Pair-programming you cover later, so I will too. Which brings us to on-site customer.

In truth, few XP teams get the luxury of having the person playing the customer role co-located with the developers all the time. The rest of us have to use supplementary techniques to ensure the reuiqred close contact between the customer and the developers. This does no have to be so close as all that, however, since the function of the customer role is NOT to be a "walking, talking, mind-changing spec", as you claim.

Rather, the customer role is to provide requirements, to prioritise requirements, to verify that requirements have been met. Since the role requires a person to fill it who is able to make business decisions about the relative importance of features, which features are required when, and so forth, it must be, and in every case that I have seen (XP projects for six different clients) has been a project or product manager, or product architect.

And in every case, these senior figures have been happy to fill that role, finding that the role of XP customer gives them an unaccustomed and very welcome sense of genuine control over the development activity they are paying for.

Finally, you present these few practices as mostly inherently valueless, or even harmful, and present the strawman argument that the "transitive closure|" of them is meant to be a self-supporting whole. This is very different from the XP position, where a range of practices (including items such as mandatory coding standards) are presented, each valuable in its own right, but (like ALL the practices, in ALL methodologies), each with an associated cost and/or risk. It is the many, sometimes quite subtle, interactions between all of the practices that allows the weaknesses of each to be compensated for by some of the others. I appreciate that this is a less thrilling image than the house of cards/ring of snakes, but it has the advantage of being accurate and thought-provoking, rather than inaccurate and panic-mongering.

Keith

Keith Braithwaite

Sat Feb 08 16:19:42 GMT 2003
re: Critique of article page 1
Hi Keith,

Thanks for the feedback, it's much appreciated.

I can see how the first page could be applied to any old [methodology] - although of course it is the introduction, so is bound to be quite general.

Even though the comments could apply to other methodologies, they do also apply to XP - and of course the article is about XP.

I think that the comments are also more applicable to XP than other methodologies, because XP includes certain practices that are more likely to entice "cowboy hackers" to the scene than other methodologies would. I couldn't imagine a cowboy programmer exclaiming, "Let's do PRINCE2 because it lets us skip up-front design and get straight to code!"

Partly because of XP's marketing, they are more likely to adopt XP, thinking (however erroneously)that it will let them skip design and documentation.

I agree with your comments about RUP: in many ways it is the other extreme. It just contains too much, and (last time I checked) contains little guidance about what to leave out for specific types of project.

Regarding your last question, I've been doing a lot of research for my upcoming book, speaking to a lot of XPers. My current project at work is also very close to an XP project, with certain key differences (I describe this project briefly in the book)...

Matt Stephens
London, England

Mon Feb 10 10:49:05 GMT 2003
RE: XP working in practice
Keith,

Your description of your XP projects brings up several questions. Like you, I have also worked on an XP project.

You state that you produced little to no design or anaylsis documents throughout the project.
- Despite this, do you feel that there IS a design or architecture in the software you've developed? Or is it merely well written individual classes that you more or less have pieced together on the fly due to no design/analysis to guide you?
- If you say that you do have an overall design/architecture in in your software, I am curious as to how this is conveyed to the following audiences:
a - new developers who may be joining the project and want to gain an understanding of the software's architecture
b - technical managers and/or technical customers who want an overview of the design/architecture.

I am hoping that you will not simply say that the new developers can look at the source code and the tests to get an understanding of the design/architecture. While this may allow a developer to understand a specific class or small set of related classes, it is certainly not an efficient mechanism for conveying software architecture and design.

- My next question relates to the life cycle of the projects that you have declared successful after development. Has your company been responsible for maintenance of these projects? Or was that the responsiblity of your customer? Have you had any feedback on the positive or negative maintenance experiences of these projects?

Sincerely,
Timothy Fisher
trfishermi@yahoo.com

Timothy Fisher trfishermi@yahoo.com
MI, USA

Thu Feb 13 06:06:27 GMT 2003
Response to Timothy
Timothy, thanks for your interest, I'll try to answer your questions as honestly and accurately as I can. Since you raise several points, I'll use a "Q&A" format.


>You state that you produced little to no design or analysis documents throughout the >project.
I sate that "we have prepared not one comprehensive requirements, analysis or design document". The key word here is *comprehensive*.

> Despite this, do you feel that there IS a design or architecture in the software you've >developed? Or is it merely well written individual classes that you more or less have >pieced together on the fly due to no design/analysis to guide you?
Certainly there is a design, and architecture too. AND our code is merely well written individual classes that we more or less pieced together on the fly. How else? But we have also continually refactored, and we have allowed an architecture to emerge. I'm sure you find that an unsatisfactory answer.
An example: we were asked to write an application to show off the features of a new industrial handheld. So we wrote a few classes to demo one feature, the we refactored, then we wrote a few classes to demo another feature, then we refactored, and so on. As time went on each additional feature became easier to demo since we grew a framework for demo-ing features that, when finished, contained exactly the kinds of classes that I'd have expected to see if we had done a really thorough analysis job on the total requirement.
Of course, we *couldn't* have done that analysis at any time before the end of the project because the total requirement wasn't known until shortly before final delivery.

>- If you say that you do have an overall design/architecture in your software, I am >curious as to how this is conveyed to the following audiences:
>a - new developers who may be joining the project and want to gain an
>understanding of the software's architecture
>I am hoping that you will not simply say that the new developers can look at the
>source code and the tests to get an understanding of the design/architecture
Then I am sorry to disappoint you. New developers certainly can look at the source code and the tests to get an understanding of the design/architecture. The key word here is *an*. We also run sessions for new developers where UML diagrams go up on the overhead projector and get discussed (and get thrown away afterwards). We also do CRC type sessions, and various other face-to-face activities to bring the new developer into the community of tacit knowledge.

>b - technical managers and/or technical customers who want an overview
>of the design/architecture.
The customer gets what they pay for. If they ask to pay for a design overview document, we do them one. We also make it clear that time spend doing the document is time spent not working on the product. Typically, they give these documents a very low priority, and we do them at the end. This is as it should be. See Parnas's paper "A Rational Design Process: How and When to Fake It"

>My next question relates to the life cycle of the projects that you have declared
>successful after development. Has your company been responsible for maintenance
>of these projects? Or was that the responsiblity of your customer? Have you had any
> feedback on the positive or negative maintenance experiences of these projects?
A mixture: some we maintain, some the client?s maintains. Of the ones we maintain, we find that we spend very little time doing "fixes", since there are very few defects (I'm talking about, for instance, fewer than 5 defects in the final delivery after 18 months development time).
The products that are being maintained by customers haven't really been in the field long enough to have any sensible data. I'll be happy to discus the outcome when we do.

Keith

Keith Braithwaite
UK

Thu Feb 13 18:21:35 GMT 2003
12_XP/AgileMethods_Evangelists vs Reliability, Safety,
Security, Integrity, Privacy, or Dependability

Scott Ambler, introducing himself as one of the 12_XP/AgileMethods_Evangelists, presented at 12ICSQ 12th International Conference on Software Quality. Ottawa, Canada. October 21-25, 2002: www.icsq.org/12Icsq.htm (Software Division of The American Society for Quality ) an Invited Lecture entitled ?Agile Modeling and Software Quality?.
During the lecture experienced QA experts and QM practitioner (some from Boeing, Lockheed Martin, Cigital) asked for evidence for his statement "XP and other AgileMethods produce high quality software". To the third and insisting inquirer Scott Ambler confessed that he can't make (and that he is not aware of) any statements regarding "XP and other AgileMethods" and systems or projects where "Reliability, Safety, Security, Integrity, Privacy, or Dependability" according "national or international rules or regulations" is an issue. As these software quality attributes are critical to professionals, non-professional end-user and the society at large it would be wise to wait until one or more of the 12_XP/AgileMethods_Evangelists can provide some insight into the relation of "XP and other AgileMethods" on one hand and "Reliability, Safety, Security, Integrity, Privacy, or Dependability" on the other hand; or some experience at least.

H L Hausen hausen@gmd.de
Rheinland, Germany

Wed Feb 19 11:55:55 GMT 2003
A realistic analysis of an actual implementation
"XP From the Trenches: Vanilla XP" is a brilliant analysis based on what actually happened when idealistic dogma was permitted to run riot in a company that had a new CEO trying to show that he was going to make an impact. He made an impact alright with I believe eight highly experienced development employees out of a total of around twenty leaving within a six month period. The middle management of R&D was totally replaced in addition to this. I agree with the author without exception. I was there and I left - with my 30 years of experience. The company was suffering from management problems, not intrinsic development problems, but it was far easier to blame and change the R&D team. XP became the tool to do this and the manner in which it was done is what resulted in the authors analysis. My bottom line comment would be that anything taken to the extreme is bound to cause a great deal of harm... and it did.
Mike Barnes socscisam@hotmail.com

Wed Feb 26 08:26:26 GMT 2003
Research into xp, Your Thoughts
I am a student researching into Extream programing. i am to create a development tool that will help people co-ordinate their xp projects. therfore i need help from the people who use XP or have chosen against using it. What i need to know is if there are any aspects that you feel could be automated inorder to make life easyer or general functions that a tool could have that would help organise. Please PLease Please reply, i need lots of opinions so as to find the functions that will best suit xp users. MY email Address is martin_john_hayes@hotmail.com please contact me with your ideas or even questions. thanks lots Martin
Martin Hayes martin_john_hayes@hotmail.com
Bangor, Gwynedd

Thu Mar 13 21:08:15 GMT 2003
Technical Rants That Miss The Point Massively
The anti-XP articles seem to be delighting in rhetoric rather than saying anything very intersting.

People who argue against test-first programming because the tests build up and make code too hard to change are simply missing the point. Tests relate to external behaviour of classes, i.e. what you're going to use the classes for! Testing internals is obviously stupid, and people doing it are simply applying a "test-first" methodology without thinking through the consequences. Testing is there to *support* refactoring.

Similarly, if people always go home at 5 even if there's a massively important deadline in 2 days, they're applying a "go home" methodology without thinking through the consequences.

If you're in a team of 2 people, and you always pair program, even if that means you can't do your job properly, because one of you is constantly being called away on support, and both of you always have to be there to program, you're applying a "pair program" methodology without thinking.

If you're spending all your time refactoring code, and none building in new functionality, you're applying a "refactor constantly" without thinking about *why* you might need to refactor (hint: you do it when changing stuff out there in the real world tells you to).

If you're always doing quick cut-and-paste jobs, because that's "the simplest thing that might possibly work", I don't want you anywhere near my workplace.

Like anything in life, XP is a set of practices with rationales. If you attempt to apply the practices without understanding the rationales, you might as well start waving chicken bones around for all the good it will do you. This is true of any process.

A central idea behind XP is to lower the cost of change. This allows an approach akin to simulated annealing, so code can follow the (often changing) processes it aims to support. It doesn't remove the need for an overall metaphor. It doesn't remove the need to constantly pull code together as you go. It doesn't help with the problem of large projects, and how to factor them into smaller projects that people can work on (XP is silent on this issue).

There is a lot of sense to the XP approach, and many of the people writing against it are simply tilting against windmills and attacking straw men of their own devising.

There is a need for constructive discussion about areas where XP-type techniques do not apply, particularly in larger projects. But simply damning all agile methodologies everywhere, in the face of evidence that they work, does not count as constructive discussion. It's just a technical rant by people uninterested in arriving at any useful conclusions.

It seems like a real shame to me that this discussion is not taking place here. What a wasted opportunity!

Matt Morris matt@arkestra.demon.co.uk
London, England

Tue Mar 25 10:35:11 GMT 2003
re: Technical Rants That Miss The Point Massively
Hi Matt,

Thanks for the feedback. I should point out that the articles are definitely not "damning all agile methodologies". There's a lot to be said for the agile values. The core message of the XP articles on this site could be summed up as: Agile values good, XP practices bad.

I actually agree with quite a lot of what you say. There are some good practices in XP that can be "salvaged", and applied with a dose of common sense. In fact this is the theme behind our upcoming book, Extreme Programming Refactored.

One of the things we discuss in the book is the problems encountered when applying XP to larger projects with multiple teams.

It sounds as if this is the discussion that you are looking for -- so hopefully it's not such a wasted opportunity after all!

Regards,

Matt Stephens
London, UK

Wed Mar 26 14:04:01 GMT 2003
Want Suggestions/Views
Hi Everybody,,

We are working on a book on XP and Java tools for XP. We have a few experts helping us. We are going for a 250 page book.

What do you think should come in? Is the number of pages adequate? Will appreciate your suggestions - views.
We might also require reviwers in future.

Bye

Babatu

babatu kimbhutkimakar@yahoo.com
Delhi, India

Thu Mar 27 14:49:31 GMT 2003
Suggestion for more comment
I'm afraid I have to agree with some of the sentiments expressed elsewhere in these messages, that "The Case Against Extreme Programming" left me feeling uneducated. Throughout, it seems to imply that XP is essentially an apostasy from traditional programming principles, whereas, perhaps in ignorance, I would have said that it is more an apostasy from practices, not principles. For example, the article strongly implies that XP doesn't involve a comprehensive design at the beginning because it holds that such a design doesn't add any value. I have never understood that to be the case (correct me, of course, if I'm wrong). Rather, I understood that a comprehensive design at the beginning is not included because to do one might be problematic and perhaps nearly impossible in certain situations.

I deeply sympathize with that idea, and would love to hear more about how the author thinks that kind of problem might be handled in a traditional framework. In my experience, it's a common problem that if we propose to spend a long initial period gathering requirements (and in some cases I've been associated with, it would be quite long), management is inclined to tell us to forget it. But, if there were a way to develop such that incremental progress is visible and usable, it wouldn't matter that the whole project takes longer than it would have otherwise. I can't say if XP is the right methodology, but it is interesting to me for that reason.

In reading the article, I had a picture in my mind of someone raising a tent and having a bystander remark, "You're doing it all wrong, you know. The proper way to build a headquarters is to draw up architectural plans, do a site analysis, dig a foundation,..." To which the first person replies, "I totally agree, and normally you'd be right. However, I'm with the Army Corps of Engineers and I'm building a command post that needs to be deployed against the enemy tomorrow, or lives will be lost. I concede that I am delaying the building of a 'proper headquarters' for quite a bit, but my approach is indispensable, because if I were to use yours, I'd be forced to conclude that the effort is pointless."

But okay, the article was funny, and I'd be interested to hear any thoughts on how 'developing software properly' could be applied to my situation.

Ernie Gutierrez egutierrez@ttwireless.com
San Francisco, USA

Thu Apr 10 19:56:54 GMT 2003
What if XP isn't right or wrong?
Matt,
I thoroughly enjoyed your thoughts on XP... it seems we're like minded given our domains are so similar. However, I don't agree that XP, RUP or any of the methodologies need to be judged right or wrong... they're all worthwhile if used judiciously; that is, if the team is constantly considering what works vs. what doesn't... the only danger with XP or any method, is when people relate to them as a religion...

There is no truth, no silver bullets, and certainly a million ways to write good (or bad) code.

peace,
-chad


chad chad@cyber-reality.com
Denver, Colorado , USA

Tue Jun 10 04:09:42 GMT 2003
re: What if XP isn't right or wrong?
Hi Chad,

I'm inclined to agree - despite the "strong words" used in the article, I do think that there's some stuff which can be salvaged from XP. I definitely wouldn't say that XP "can't possibly work", because there are projects where it has worked.

Although XP has some fundamental problems, its agile goals are about right - just the implementation is poor...

My upcoming book "Extreme Programming Refactored" discusses this idea in detail, and suggests some ways to achieve XP's agile goals using more robust methods.

Matt Stephens
London, England

Tue Jun 10 11:19:21 GMT 2003
is xp realy working for structured engineering?
hii would like to know whether xp works when doing a structured software engineering. plz reply by email preferably
thanx

tshepo mchapa@webmail.co.za
polokwane, southafrica

Mon Jun 30 13:26:16 GMT 2003
XP Testing Without XP
Summer 2003 Issue of Methods & Tools

Methods & Tools is a free e-newsletter for software developers
Summer 2003 issue content:
* XP Testing Without XP: Taking Advantage of Agile Testing Practices
* Modeling the Real World for Load Testing Web Sites
* When can the software be released?

To download or read this issue go to
http://www.methodsandtools.com/mt/download.html

editor
Switzerland

Wed Jul 02 12:14:29 GMT 2003
XP Article.
I would like to talk to some non-technical business people that were successful in allowing their technical organization to impelment xp
for one or more development projects and the
results.

Pair programming is not as efficient as solo programming period. I am doing it now for the first time and the initial results show that with a pair i am 25% as efficient alone. And my pair doesnt write as clean as code as me, so when he
codes the code is lower quality then when i
code.

The test encouragement of xp is not a novel idea, its been around for years. What i dont like about xp is that they come up with these "bright" ideas and think they invented them. Every xp idea has been used in one fashion or another by developers over the years. Its just that the developer used the idea, and then went on to do his job, rather then make naming, and forcing the idea on development groups his evanglistic goal and job.

see "xp coach"

-Paul-

Paul Wolfowitz pwolf@yahoo.com
Washington, USA

Sun Jul 20 05:39:25 GMT 2003
Creativity and Flow
I was interested to see you cite Mihaly Csikszentmihalyi's theory of Flow in your criticisms of pair programming as this is something I had referenced in my studies (in a previous life as an accountant).

I did think it odd that you focused so keenly on the solitary aspects of this, especially as the example you quoted, "like playing jazz", is something that is primarily done in groups.

I was not aware that there was anything inherent in the concept of flow that meant doing something alone was better. If you think of a good conversation you have had recently you will recognize the same elements of time passing quickly and feeling creative sparks as you work together with others to construct the conversation. I believe sports psychologists sometimes refer to this form of team flow as gelling and in fact Csikszentmihalyi co-authored a book on flow in sports that was endorsed by Miami Dolphins coach Jimmy Johnson.

Csikszentmihalyi also talks about the application of flow to personal relationships such as marriage which again are obviously not solitary pursuits and emphasises how working with a partner can in fact raise challenges that help you achieve and maintain flow.

(for those not familiar flow is an optimum state reached when you are neither bored nor overwhelmed by whatever task you are involved in. Obviously over time, as you gain experience, the difficulty of the task must be ratcheted up to avoid boredom but not so fast as to prove discouraging.)

As a final data point I also remember hearing someone discuss pair-programming as a positive boon to achieving flow as the normal day-to-day workplace distractions of phones, colleages needing a question answered etc. can be fielded by the non-programming partner allowing the other to achieve some continuity of focus.

anon

Fri Aug 08 12:06:30 GMT 2003
Why process?
Everybody wants a magic bullet. Some think more documentation makes development better... some less... some like tons of process and procedures... some like virtually none. The fact remains that there are successful examples in almost all mutations... So, maybe it's not really so much about the process as it is about the people in the process.

If you have talented, capable people, then you can probably accomplish your goal regardless of the process... and I think that often the case is probably in spite of the process.

But back to the magic bullet... why do we need a process anyway? I don't think most people really think about that. They just hear success stories, or recall something that they may have at one time been a part of that worked... then they think that is the best way to do it. When in reality it may be one of those cases that the talent of the people made the success in spite of the process.

Every project is different... every team is different... iteration to iteration is different... there are always different destinations... when you go to the beach, do you use the same route that you use to get to the mountains? Most every turn is different. Now, you could argue that it's only the details that are different, but generally it's the same thing (you're driving your car the same way... putting in gas... etc.)... but do we even consider that with process?

Every decision is an economic one. Most people don't or won't consider that. There is a cost associated with everything... even if it's only the cost of not doing by doing. In software development, we have a goal which is to provide to a customer what they want and need a software system to do. Our costs are the resources it takes to meet that goal (people, time, harware, software, etc... which all translate to $).

I think the best process is the one that meets the goal and minimizes the cost... but... keep in mind the goal is different project to project, iteration to iteration. A heavy process doesn't work well to minimize the cost of a really small effort... it burdens the effort with much more work than neccessary to meet the goal. A really light process doesn't have enough structure to efficiently manage the development of a huge effort... too much time is spent refactoring and reworking existing code... too much duplication of effort will occur. A business with 5 employees functions completely different than one with 50,000 employees. It has to.

What we have to do... with any methodology or process... is ask, "Why are we doing this?" If there's not a good reason, then don't do it... sometimes there is unproductive overhead required... sometimes the unproductive overhead is completely useless. But to be successful... to minimize the resources required... we should ask that question of everything we do everytime we do it... or don't do it... maybe there's a better way to get requirements this iteration... but we have to question ourselves and be comfortable with changing the way we work... we can't let habits and old comfortable ways be our process... otherwise, we will rarely do the best job we could do.

Jason Craven jcraven@1three.com
GA, USA

Thu Sep 04 14:57:06 BST 2003
Peer programming
Peer programming always struck me as a bit strange. Not because 2 programmers work better sharing ideas and decisions - they do. But the the assumption that 2 programmers must share ideas and decisions all the time.

I could accept that some key aspects of design may need more than one head - but that's called brain storming.

I don't know about the software engineers you employ, but a bottom line for me is not to employ anybody who doesn't know when to ask for another persons opinion at the right time.

Robin Sharp robin.sharp@javelinsoft.com
London, Surrey

Fri Sep 05 08:42:53 BST 2003
No plan = doom
I work in visual effects, the storyboard and script are an essential part of our everyday job.The idea of creating hollywood level effects without a foundation is utterly ludricous. You can't just carry a camcorder and some actors around for a year and hope to create Lord of the Rings complete with animated ringwraiths and a fully cg Golum, without a detailed vision worked out on paper, (a substance infinitely cheaper and faster to work with than any digital tool ever developed) and a schedule to adhere to. Programming is not so different from producing a movie. Since Extreme Moviemaking sounds ridiculous and unfeasible, shouldn't we make sure the emperor's not running about naked here?
Fred

Tue Oct 07 01:38:57 BST 2003
customer doesn't have to be a...customer...
matthew,

i've been reading your case against XP and although i feel you do have valid points, i think in many cases you take a lot of the preaching too literally (much like the bible could be?!)...

you talk a lot about the cost of having a permanant customer on site and how you won't get a serious decision maker onboard as the customer. i feel where you are wrong in your statements is that the role of "customer" in XP can be played by a "customer buffer".

lets take an example of say UberHax0rConsultants doing a job for MassiveFirm. UberHax0rConsultants hire out a customer (who can double as a "project manager"). this customer divides his/her time between MassiveFirm workshops (to which he/she may wish to bring a developer occasionally to give them a first-hand view) and working closely with the engineering team. this "professional customer" therefore represents the collective sentiments of MassiveFirm's project team.

michael
london, uk

Thu Oct 09 11:25:55 BST 2003
To XP or Not
Seems like one side says its not XP if it fails. The other side says its not XP if it succeeds. From that I conclude there is no such thing as XP or that everything is XP. If so, why should I care either way?

XP is ONLY a tool. Just as a 5 lb sledge hammer is a tool. You break big rocks into little rocks with a sledge hammer but you don't fix watches with one. Why do you think XP will work for all problems, with all people, in all circumstances or that it won't work at all in any circumstance?

The real question is what are the project characteristics for success with XP and what are the project characteristics when XP will fail? Ditto for every other prepackaged, cult like, I have a book that tells the one true way for sale, methodology out there.

I say strip the crap and get down to what works, why, when, and how. Then use the various tools with understanding and intellegence. That's what I have done since I started developing software in 1965. I have been quite successful and outragously productive as a consequence.





Lionell K. Griffith griffith@syv.com
Solvang, CA, USA

Thu Oct 09 18:07:00 BST 2003
the new methodolgies, pick your side and join in your very own holy war!
Matthew,

I felt your article touched on some very important points and key limitations of a vanilla implementation of xp.

the first thing i will say, is that as frustrating as xp is, you shouldn't let your frustration from using it manifest itself in the form of 'schoolyard' comparisions. i too feel some of the practices of xp are pieces of shit, but it's no way to convey your point :)

what i really wanted to say is that i found your article amusing, and at times i was nodding in agreement or laughing to myself! with some more work i feel that this article could be a turning point on my pet hate. AGILE = XP

i want to personally kill a certain marketing machine that i liken to a microsoft media juggernaut for polluting the agile community. He has done wonders to make middle management worldwide aware that agile exists, but unfortunately this has had the same effect of all computers should come installed with windows xp.

borland have it right.
----------------------
goal: i do not know what i want to build. it is of an ultra high risk in that i dont even know what it is that i want. it will be for internal (or very least small customer), and be developed by a few developers in a short time frame, as i dont want to lose too much money on this if i decide this project is not for us. answer: use an organisationally alligned xp version. my experience: xp is a great way to do this kind of work. it will and does suffer from scalability. anyone who wants to argue with me probably likes to pick fights in their local drinking spot as well. anecdotal evidence is enough to support it doesnt scale period... and dont get me started on the implementation of tdd that xp uses.. ergh..

goal: my software requirements are detailed so much and will change very infrequently. this is as a result of a previous projects requirements analysis or an evolution of a current product. answer: an organisationally alligned version of rup or similar. my experience: well there isnt any! but it just works. rup isnt evil, its not nasty it serves a purpose and it still does it very well.

goal: i have a project where i know what i want, but not fully. requirements will more than likely change a decent amount but a good requirements analysis should elimiate a fair bit of this risk. answer: fdd (scrum too!). my experience: i wont lie to you. anyone who has done a vanilla implementation of fdd with 10+ developers, will never go back to their old methodology. why? fdd sits perfectly in the middle of xp and rup. its 5 pages means everone knows what the hell is going on without reading 20+ books. fdd does not mandate you do something one way or another. it serves as a container to move your projects forward without the crap. of all the methodologies this is my favorite for any large scale (10+) development. it doesnt scale down and i dont care.. i can use something else for a smaller project. but if you want to pick a methodology to establish your own organisations best practices. look here first. blow the belt quote: at least in its first guise fdd managed to deliver the right product on time with 50 developers over 15 months. :S hehe

my conclusion: your organisation shouldn't be aligned to any one methodology. invest in knowing whats out there. i dont know about most of you, but i am results driven. all methodolgoies have their good points and bad points. i have a pro cons list of all of them, and eventually i might write a paper. in todays world however fdd as a baseline is as close to a sure bet as you can recieve in our industry.

cheers,

::mark

Mark Angrish this_is_not_a_stop_sign at hotmail dot com
melbourne, australia

Sun Oct 12 07:24:29 BST 2003
The problem is really the "extreme" part
In and by themselves all of the XP principles contain good advice. Damn good advice, in fact. Stuff which most good programmers have discovered naturally. (Which also answers the "don't knock it before you've tried it" mantra.) Which is why the hype sounds so compelling.

The only problem is the "turning all the knobs to 10"... and ending up with a complete stupidity. It's like saying "salt and pepper and vinegar are good in a soup, so let's turn it all the way up and make a soup _only_ with salt and pepper, boiled in pure vinegar." Would you eat that? I wouldn't.

E.g., back to the principles:

- Writing easily readable code? Sure. Any good programmer will strive to do that. But having the code be the _only_ documentation ever is simply _retarded_. And has been known to be retarded for ages.

In any project which isn't trivially simple, it ends up 2 years later with some poor maintenance SOB having to read through 1000 classes to find out what he needs to use. That's pure wasted time. Or will _you_ still remember perfectly which classes you need to read, after 2 years? More wasted time and productivity.

Doubly so when people from other teams and projects have to interface with that code. Can you imagine anyone using J2EE or .NET if the _only_ documentation for those was the source code?

E.g., WebSphere 5 has 54 megs of jar files. The probably means a several hundred megs of sources. Picture that there was no documentation and no formal spec, and you had to actually read those hundreds of megs to figure out how to write a servlet or EJB. See the utter retardedness of that idea yet?

- Unit tests? Great tools. Everyone should be using them. But having the unit tests be the _only_ test, is pure idiocy.

The job of a human tester is precisely to think laterally and try to break the application in ways that I or the client rep never thought about. The cases I can think about, and thus go into the unit tests (and acceptance tests), chances are I've already tested for in the program itself. What I need is someone who never even saw the code, sees only the GUI, and uses his own human intelligence and creativity to try to break it.

In that vein, I'll go and say I'll have trouble taking seriously a methodology from someone who thinks that testers finding bugs only serves to embarass and humiliate the programmers? Hello? Those guys are doing us programmers an invaluable service. You should encourage them, not make them feel as if they're your enemy. If you feel humiliated by this service, you shouldn't even be in this industry!

By "elliminating" them from your team, you only pass this job to the client. Your client (or in the case of a web app, your client's clients) gets to see a buggy application, and act as your unpaid beta tester. That's lame. That's what gets this industry a bad name in the first place.

- Two heads are better than one? Damn right. I've spent some 20% of the time in the last project, either sitting at someone's desk helping them, or receiving the same favour in return. The keywords however, were: "when needed".

But doing it _all_ the time, is just retarded. It brings nothing but broken concentration, and uses two people for routine tasks that one could do just as well. Will two people write trivial stuff like deployment descriptors or data objects twice as fast? Well, no, they'll in fact write them slower than either of them would have on his own.

- Being prepared for requirement changes? Perfectly good advice. All the methodologies developped in the last half the century, including OOP, had ease of change/maintenance as a goal.

But completely throwing away any design work and just changing everything all the time, until it sorta fits what the client wants, is purely idiotic. I've actually been in large projects operated that way, and it was just pure chaos and purely wasted work.

No matter how easy it is to change something, or even throw it away and start from scratch, you can't erase the wasted time of writing the useless code in the first place. If you've spent 2 man-months writing code that was thrown away, no matter how easy that final transition was, that's 2 man-months worth of wasted money. (And at least in one project it was more like 2 man-years total only in pieces scrapped completely.) Some up front design could have prevented that.

- Refactoring? Perfectly sane idea. Please do refactor whenever it's needed.

But the whole attitude that "continuous refactoring" and lack of deadlines beget is "heck, it doesn't matter if it's right the first time, or even in the right direction, it can always be refactored later. We'll just bill the client for the time taken to refactor too". That way lies underachievement. Once you're thoroughly in that state of mind, code quality goes downhill in no time.

- Not coding stuff that isn't needed? Perfectly sane advice. Those of us who didn't yet get rid of the "big design up front", will tend not to code stuff that's not required in that spec anyway. Rest asured that no good programmer will code a funkier load dialog than the client asked for.

But taking the whole "the simplest thing which could possibly work" principle literally is a recipe for disaster. Literally the simplest possible thing to code is stuff like monolythic servlets (or other monolythic code that mixes the model, view and controller in an unstructured whole) and spaghetti code. That's very easy and quick to write.

But there's a good reason why the rest of the world considers that to be an anti-pattern. There's a reason why not only we'll only use that in demos, but insist that that code never be used as a productive version. The work required to maintain or change (or refactor) it later increases dramatically.

And so on, and so forth.

Moraelin n/a
Germany

Fri Oct 24 17:32:04 BST 2003
manager's view of XP, one year of using it
I am the president of a small development company. We have been using XP for more than a year. I think parts of it work but others don't. Code is not "owned" by all of our programmers. Our best programmer tends to refactor other people's code a lot. He is a talented person, but is too much of a perfectionist to share code.

Pairing works ok, but it does not offer as much as it promises. You have to be pretty high level to bother with it at all. A lot of people simply are not into pairing. We have had turnover related to this.

My biggest problem with it is that when I have a problem with the way things are going, my programmers tend to tell me that it is a "business" issue that has nothing to do with them, or that I have prevented them from practicing XP as it should be. XP simply does not deal with the politics of business. When you read something that says you need a good customer to use XP, take it to heart. You need a great customer to be able to use XP! I would estimate that only about 5% of the customers I have dealt with in my 10 years of doing development would be able to handle a true XP project. I would estimate about 50% of programmers can deal with it.

I have other issues with it, but those are the main ones. We will continue to use a more customer focused version of XP. We do some upfront design, are not too focused on refactoring, work overtime when we have to and meet fixed schedules and budgets. I have yet to meet someone in person who has applied XP in its Utopian form (plenty claim to online). I am looking to the next generation of thinking on XP as I think the first gen have run out of gas and refuse to address some of its obvious flaws.

ron zart@myway.com

Mon Oct 27 09:09:39 GMT 2003
Then IMHO it's not XP
Dunno, Ron... If you start refactoring it into something sane, that actually works, and that your customers can live with, then you're really no longer doing XP. (And that IMHO is a good thing.) The whole XP idea is literally about blindly turning all the knobs up to 10. That's why it's called "extreme" in the first place.

Sort of like the "extreme sports". There's a difference between driving a bycicle to work, and driving a bycicle off a ramp to jump between two rooftops. The first is actually sane, the second is "extreme". If you take the extreme version and refactor it into "we'll drive a bycicle sanely on the road instead", you just lost the "extreme" part.

And if you're already at that point, IMHO you're better off giving up on XP completely. Please do read the XP books and read them well. Extract the useful advice from the hype. There _is_ some good advice in there. (E.g., using unit tests, or pairing when someone actually could use some help, or refactoring when needed.) But lose the "extreme" part and apply those in a sane development process.

Turn the knobs not to 10, but to whatever value actually works the best in your project.

Moraelin

Wed Oct 29 08:11:29 GMT 2003
How could anybody be against XP?
After all, if you want poorly defined goals and immeasurable results, XP IS MADE FOR IT!

Sit paired up in an office in front of a computer letting your "partners" do all the work, pausing briefly to produce (and reproduce) code that always needs "refactoring" by some other team member, and then get another job a few months before the time runs out on the current one, so your resume looks GOLDEN! (Remember: you left for FAMILY/PERSONAL reasons.) With a long enough timeline, you can even be a lead on your next project - and recommend *Extreme Programming* be used there, too!

Anybody who enjoyed 'The Way Of the Weasel', by Scott Adams should appreciate what a brilliant invention this is. (Not for shipping products. Heavens no! A means to stay employed for lengthy periods of time without producing anything that ever has to work right while padding your resume for future jobs! Leave at 5:00pm, and start fresh in the morning like yesterday didn't matter? Anybody like Dilbert's Wally would love it!)

After all, if it's a total failure, "We weren't REALLY following XP right! Management wouldn't let us! People didn't cooperate! It's NOT MY FAULT it failed!"

Now put your hands on the screen and PRAY we'll ship a product.... If we don't, you weren't sincere enough! Your faith wasn't great enough! You didn't believe enough! Amen!


David Mace evildave@sti.net
California, USA

Thu Nov 13 05:38:19 GMT 2003
RUP & XP
RUP is the most popular of the "heavyweight" processes bacause it makes a lot of sense. XP is the most popular of the "lightweight" processes because it makes a lot of sense. But none of them make complete sense. This is because they are both just a catalog of process best practices and each element in the catalogs cannot possibly apply to every project, otherwise every project would be the same.
What a project team needs to do (and this boils down to the project's software architect(s)and senior developers) is tailor its process by picking elements of these two processes according to the needs and demands of the project.

However, I do like the "Extreme Programming Refactored" book as it at least gives a voice to the people who are bothered by the sect of very annoying (and often silly) XP crusaders (who always seem to find their way into every project I work on).

tony yayo

Sat Dec 06 23:11:51 GMT 2003
General comments
Well ... from reading through the feedback and the articles themselves, it seems like:

1) XP does not necessarily apply to any and all projects

2) But people have genuinely used it to create real life, working programs - sometimes very good ones.

This tells me that the biggest factor might be individual "leaning" / appropriateness of the method for their personality.

To the XPers: try not to make "extreme" statements about extreme programming ... it obviously works sometimes, but not other times. If it always worked, it would always work - no need to blame the people who tried it unsuccessfully.

To the anti-XPers: same thing - it obviously works sometimes. No need to attack these guys !

Personally, I would like to learn as much as I can from people of other disciplines and backgrounds ...

David F

David F nospam@nospam.com
Sydney, Australia

Thu Dec 11 10:35:27 GMT 2003
review of XP Refactored
Apparently I pissed off someone. My somewhat detailed review of XP Refactored, posted in September at Amazon, has been deleted after being there for three months. In fact, it was the "spotlight" review for a while due to the large number of votes (almost equally positive and negative) it received for being helpful or not.

I can only surmise that either the authors or another XP-hater complained, and forced Amazon to remove the two-star review. (My review did follow their general guidelines, other than perhaps its sin of disagreeing with McConnell's ass-kissing review).

In any case, it's one thing to dismiss other people's ideas in a book that you managed to get published. But to quell honest, dissenting opinion by getting Amazon to excise reviews is cowardly.

Jeff Langr JLangr@Yahoo.com
Colorado Springs, CO, United States

Wed Dec 24 20:14:32 GMT 2003
re: review of XP Refactored
Hi Jeff,

If you have a copy of it, feel free to post the review here, I won't remove it.

You'll notice that I also link to Ron Jeffries' "bad" review from this site, so I'm not against dissenting opinions. If I remember, your review did contain some oddities though, e.g. accusing the authors of making up correspondents (I can say for certain they're not made up!) and of being over-priced consultants (I wish that were the case...)

Matt Stephens
London, England

Fri Dec 26 11:56:46 GMT 2003
re: XP refactored review
Hi Matt,

Thanks for the offer. I'll consider it.

There was at least one blatant factual error in the book. And while that normally wouldn't matter, when the facts are distorted in order to slam something, you're going to get called on it. Particularly when a lot of your book is about calling others on the carpet for *their* errors.

As far as the "made-up" testimonials, apparently you missed the humor in that. I did a search before I posted the review, and I'm aware that the guy I referenced as "made-up" does indeed exist (or at least appears to). The point is that it's easy to offer lots of cocksure opinions when you're hiding behind anonymity. And they're just that--one man's opinion.

Overall I thought the book was reasonably well-written (except for the excessive use of name-calling), and I found some good nuggets of truth and wisdom. But I also found many things that just came across as overly biased and uninformed. I do understand where the frustrations come from.

I think that you could have increased your readership were the book not so "extreme" and personal in nature.

Best regards,
Jeff

Jeff Langr JLangr@Yahoo.com
US

Fri Dec 26 14:47:15 GMT 2003
Wired Article
Yes, the Wired article is truly daft, written in a style guaranteed to induce the cringes. However, I think you're totally mistaken in your interpretion that it's accusing those who don't get XP as having a 'genetic defect'.

It is, I believe, referring to research showing that programmers (and engineers in general) have a much higher than average rate of certain autistic traits that allow their minds to map out complex systems much, much better than the norm.

Although you seem to re-interpret everything (particularly about XP) to suit your criticism, elsewhere here, you do make the brave and valid point that far too many developers are way below even mediocrity. These are those who don't have the aforementioned traits and hence just drag the rest down.

And thus is the truth about development: the process, whether XP or waterfall, cannot make bad developers good, but it can ruin the best. It's The People that will make a project succeed or fail. I am dubious about the claims of XP, but it appears to me that traditional methods can provide lots more time-consuming bean-counting busy work for those WITHOUT the mind mapping genetic advantage.


Arthur Bitter ferocious.beast@nowhereland.com
Over there, yes

Fri Feb 06 15:21:52 GMT 2004
review of XP Refactored
Thanks for the link to my excised Amazon review. I noted this amusing quote from your blurb about the review:

'Langr accuses one of our correspondents of not being real, then gets angry because the same correspondent declared that he has "13 years of software development experience", as if that's a crime.'

Apparently you lacked the sense of humor to get the joke in the review. I at least "got" some of the humor in XP Refactored. Perhaps "hate," "paranoia," and "anger" have different meanings in the old world; I'll have to check Oxford's.

In any case, good luck with the book.

Regards,
Jeff

Jeff Langr Jeff.Langr@LangrSoft.com
Colorado Springs, United States

Wed Feb 11 00:39:46 GMT 2004
XP not extreme enough
These days RealProgrammers are moving to iHyperProgramming(tm): eVenMoreExtremeThanXtreme.

In this, the entire team sits around one keyboard and monitor (which should be a "wyse" terminal). The release cycle is once per line of code (see below for a productivity tool that enables this paradigm). There is no on-site customer or requirements spec: the programming team itself chooses the requirements[1].

[1] Usually based on the "meta-requirement" to fill holes in their CV.

XP's TheSoftwareIsNeverFinished has been abandoned since the Wage Monkeys (=Gold Owners) sometimes dispute this and attempt to withold wages. iHP's scheduling motto, ~oTheSoftwareIsNeverStable, is much more effective at securing the ongoing co-operation of the Wage Monkey. In fact iHP projects can only ever terminate with the departure of the iHP developers (who are required to spend >75% of their career writing books and participating in Usenet discussions to keep themselves "sharp").

The members of an iHP team are all equal apart from one special member who is more so because of his 3 responsibilities:
1. Monitoring the iHP|uAdherance of other team members.
2. Making sure the (single) keyboard is frequently sanitised.
3. Wagging his tail continuously to motivate the team.

This member is called the Wag eMon'Key, and has the additional benefit of forcing anyone learning HP to rea dmores lowly.

iHyperProgramming regards code as a daft way to document a system, since its meaning is highly subjective (ever tried porting from gcc to Visual C++?). Object code is worse because if a project were ever ported to an interpreted environment, then there would be no documentation, and we couldn't have that.

So iHP uses the error output as documentation: since ~oTheSoftwareIsNeverStable, more documentation is generated every time the program is started. This doumentation is authoritative and yet completely free!

Wheras XP provides only written literature to enable its methodology, iHP provides the following free[2] productivity tool, the iHP://uSourceManagementTool ("HP source" for short):

#! /bin/bash
while(1); do
readline >> program.c
g++ program.c -o program >> documentation.txt
./program >> documentation.txt
done

[2] On the condition that you never write code for money again in your life.

John jgraley@rioaudio.com
Cambridge, UK

Tue Feb 24 14:59:50 GMT 2004
Team composition
I'm currently researching a report for a Computing MSc I'm doing, basically a case study for an imaginary firm's IT department as to whether or not to start using RAD techniques (of which XP appears to be one of the more adventurous).

The research I've done included dipping into some of the old management chestnuts, including "Management Teams: why they succeed or fail" by R. Meredith Belbin. This was in response to a suggestion from the DSDM Manual that all teams should consist entirely of "good communicators".

Initially, I assumed that this would contradict what Belbin states, (which is echoed by a lot of other texts on team-building)- namely, a good team consists of a balance of personalities, and a team made up entirely of chatty, communicative types would be doomed to sit around "interacting" and never actually get anything done.

What Belbin actually found was that teams made up entirely of people with similar personalities were generally unsuccessful, EXCEPT those made up of what he calls "Stable Extroverts"- i.e. people who can both put forward their own opinions and take the opinions of others on board.

However, he also noted that those teams most likely doomed to failure were those made up of "Anxious Introverts"- a stable of people who like to be left alone to solve problems in their own manner. He attributes most extremely creative people to this category, and I think it's fair to say that a lot of really talented programmers fall into it, too. (Certainly the best programmer I've ever worked with does: he hated meetings and always thought long and hard before he spoke- the result being that he always had something sensible to say).

Belbin also notes that, while teams of Stable Extroverts (i.e. chatty b*stards) are much better than all other "pure" teams, they still can't compete with teams containing a balance of personalities. They tend towards the kind of sloppy mistakes and lapses in concentration that more introverted personalities will pick up on or avoid.

The arguments raging on this board (about pair programming in particular) seem to reinforce these findings. XP, (and a lot of other RAD techniques) seem to embrace work undertaken by small teams of outgoing people who are comfortable communicating their ideas. But if this is, by nature, excluding a whole type of personality that is very well suited to programming, it's no wonder that RAD / XP has a reputation for being unsuitable for complex projects.

If, on the other hand, your XP team is made up with a majority of expert programmers who tend towards the introverted, self-managing, problem-solving category of personality, then you're entering territory that Belbin would no doubt argue was extremely risky.

David Gerrard dave@dgcv.co.uk
Leicester, UK

Sun Mar 21 16:21:41 GMT 2004
Does XP really solved any problem?
Could XP be a new 'silver bullet' for software development? I don't think so.

Simple design, simple planning, refactoring, all these are attractive, and it looks like XP can postpone everything. Why postponing, 'because something is too complicated and dynamicly', so how do you estimate the cost and workload? When you refactorying later, how do you lower the cost of postponed modification? And how XP solve the problem of severely increased amount of communication within a team? Don't only say it needs practices, practices are nessasory for any method, and it is very hard to specify.

I think the boundary between XP or UP or any process are very ambiguous, many consepts are interlaced, any method sacrifice some things for other benefits, it's better to say XP provided some new ideas and make us think over other methods again.

xpandy hsesual@yahoo.com

Mon Mar 29 08:08:16 BST 2004
I would like to know how might Extreme Programming be adapted to handle the integration of licensed software? Is is possible? What would be the negative effects and the positive effects if we adapt COTS? I would appreciate if you please reply to my e-mail address (vianca@hotmail.com) not the Forum. Thank you, Vianca.

Vianca vianca@hotmail.com
Germany

Tue Apr 06 16:58:50 BST 2004
Matt Stephens - Pair "Authoring"
Matt:

Read some of your articles. Looked at your book.

I noticed you "pair-author" a lot - or I guess you call it "co-author." How does that work exactly? Do you do the thinking and the other guy the writing? Or do you both write and leave the thinking to others?

Also - sounds like you re-worked your original book design - "in fact, we received so many of these contributions that we worked them into the book as a series of sidebars..." I think XP'ers call that re-factoring.

How come you didn't recognize these "contributions" during your detailed requirements phase up-front? Did your book design change when you decided "to work them into the book"? The book design must have changed to accomodate these sidebars - meaning you allowed your design to evolve.

Hmmmmmm - you say one thing in your articles but sounds like your a closet XP'er !!

I've been managing software development projects for over 25 years. (I guess that makes you 6 years old when I started.) Based on your articles - I don't think you know what you're talking about.

Outside of writing your book - have you ever developed a software project using XP practices?

DCarlson carlsods@tvratings.com
Florida, USA

Mon Apr 12 20:20:32 BST 2004
re: Matt Stephens - Pair "Authoring"
Hi DCarlson,

This recent article (the transcript from a talk I gave) should answer your questions (in particular about how many of the XP practices I've tried):

http://www.softwarereality.com/lifecycle/xp/extremism.jsp

The main argument that we make in the book is that XP can work but it's high risk, but can be strengthened by applying some changes to the practices.

Hope that helps,

Matt Stephens
London, England

Mon Apr 12 21:56:41 BST 2004
I have undone thee!!!

Ah, Mr Stephens, we missed you.

I suggest that you, Mr Stephens, talk to other people.

I also suggest that you take input from others.

I also suggest that you sometimes test you assertions against reality.

As we all know, none of this existed before XP,
and none shall exist after XP. Hence and therefore
all the above is of XP, and nothing else.

Given this, it is more than apparent that you are in fact an XP stooge, programmed by the Jeffries construct to sow dissent and disorder in the XP ranks, to tempt the naysayers out with your sweet sounding ivory tower 'logic', from whence forth the Angels of eXtreeeeeeme retribution shall lay waste to their forward designing hearts and minds.

Your work is done, wake up, wake up, back to the mothership...

Dino Fancellu
UK

Tue Apr 13 08:45:56 BST 2004
Is there a site like this for debunking the linux hype?
I'm more sick of linux than xp and wish there was a site like this that shows how crappy linux is in a witty fashion
I4get

Mon Apr 19 23:06:02 BST 2004
Manager QA Extreme Programming/Testing needed
Need assistance finding a QA Manager for new team working with Extreme Programming and Extreme Testing.

Thanks

Larry Zeichner eXT@uscareers.com
Cleveland, Ohio, USA

Fri May 14 18:55:37 BST 2004
I actually wasted time reading this !!
After reading this stuff, I felt my dinner wanting to come up and visit the porcelin alter. I'm amazed at what some people will do to get noteriety. The author of this "National Equirer take on the XP process", either is attempting to drum up business,
or is just plain scared of the dynamic "REAL" world in which we develop software. Like any methodology, there are pros's and cons. And, the answer to a given solution normally falls along the happy medium spectrum. I have known many projects that have failed by doing too much design work up front, only to find that the requirements need to change based on a changing market for a given business domain. Now what happens.The development team goes back to the drawing board,
to reassess the changes. All this occurs without
so much as even a single demostrative "hello world" kind of prototype finding it's way to the desktops of the "powers that be". I for one am a strong proponent of the rapid build,fast feedback,
and rapid deliverables camp. I thik a client would much rather be looking at something on his/her desktop
other than a pile of elegant documentation. Besides the obvious advantages stated above, there is always the side effect of rapid releases, and that is identifiying potential spike or difficult areas up front. Something that "bulk design up-front" has a poor chance of doing. Then there is the comfort level that is established by user stories. These stories are after all in the language of the end users and business people.
I mean, isn't that who we are being paid by. And finally there is this. While at the client site, on a friday after-noon heading close to 5:00PM, notice the smile on a client's face when he/she actually sees somthing, anything working. After only a short period of time on a project. That beats the hell out of the user looking down at a pile of design documents, and a lot of arm waving ANY day in my book AND more importantly THEIRS too.

Kevin J Citron kjc5664@yahoo.com
EL Paso,TX, USA

Fri Jun 04 05:09:29 BST 2004
I agree... you do need documentation, design, prototyping first

When reading "XP Rule: No Requirements, Just User Stories", I was reminded of something a friend went through.

She was a writer and got a contract from a company to write a sales brochure. There were some vague "user stories" on what the brochure had to say and look like.

Unfortunately, there were countless iterations. Each time she wrote something, the client wanted to change a bit here, add a bit there. Things added after one meeting were removed at the next.

The client had no idea what the final product was to be and was unwilling to accept what my friend had written.

My friend finally walked away from the project in frustration - even though the client was willing to pay for more work!


Leo Jacob
Portland, OR, USA

Wed Jun 09 22:49:42 BST 2004
my 2 cents
Some time ago a client asked me if I know about XP. I didn't. I just thought it sounded somewhat fishy. I lost that client to an XP team, and heard from them once: the client needed an urgent fix to a screw up that could be prevented simply by reading the HOWTO document. (Since XP people are reluctant to write documentation, I guess they don't feel the need to read it either). The said team meanwhile was already doing something else extreme. Well, none of us are angels, I thought, and that was that.

Hearing more and more about XP, I tried to find out about it. I am a self-educated programmer, and XP strongly reminds me my own fallacies as I progressed: absence of documentation; desire to talk about and try new things right away; litter of post-its; constant refactoring; need for someone more experienced to sit next to me so I can ask questions instead of RTFM... hackish amateurism, but turned into theory. The theory, meanwhile, seems more like a bunch of InterLinked WikiWords. Hardly a single substantive definition, just circular references.

c. colombo

Thu Sep 30 22:36:20 BST 2004
Poor Design
I've just joined a company that uses the XP methodology. I come from a formal software engineering background. I was certainly under no illusions when joining the company. I figured it would be a good experience, possibly see how things are done using a different methodology.

I've been with the company for almost a month and I'm absolutely stunned at the poor quality of the code. In my wildest dreams I wouldn't have imagined how quickly the system would tend to a state of complete decay.

I've attempted to present some of the more common and useful patterns as a means to show the benefits of up front design in the software development cycle. Although some patterns are in use within the code, they are either wrong or incorrectly implemented. My impressions of the code are that it is inconsistent, inflexible, slow, inefficient, etc. etc. etc.

On average I spend a third of my day waiting for integration tests. On the odd occasion that I try to explain why a particular design would be useful in a scenario, I'm shouted down and told that I'm either thinking too far ahead and that it isn't necessary yet or that I'm being over complicated. This is even if I can virtually guarantee that a design *will* fufill future requirements.

From an initial inside perspective of XP (they seem to try to follow the methodology quite closely), I think it is woefully inadequate, it's proponents are hopelessly uninformed and ill-disciplined and the software we produce is buggy, difficult to change and painful to work on.

I truly regret having accepted this position.

Darren
South Africa

Wed Oct 06 20:41:16 BST 2004
Going round and round and getting nowhere eXtremely fast?
The Methods & Tools newsletter has just released in its archive section the article "Going round and round and getting nowhere eXtremely fast?Another look at incremental and iterative development". This article defines the different process available for software development projects and when and how to use them

http://www.methodsandtools.com/archive/archive.php?id=14

Anonymous person

Wed Nov 10 12:06:42 GMT 2004

 

Page 1 (earliest)

Page 2

Page 3

Page 4


<< Back to XP Central


<< Back to Software Reality


All trademarks and copyrights on this page are owned by their respective owners.
Stories and articles are owned by the original author.
All the rest Copyright © 1998 onwards Matt Stephens. ALL RIGHTS RESERVED.