Design within the XP process

[jason adam]

Been curious about this, and since this weeks give-away is within this forum, decided it's a perfect time to ask From what I have read (from Fowler, extremeprogramming.org, etc.), I like the process, but wonder how it is actually working in the real world.
My OOAD facilitator, who leans strongly to the XP side, has found that the majority of the projects that he has worked on that utilized the XP process were pretty much a "license to hack". He's quite a learned fellow and is very aware of XP's best practices, so this wasn't an uninformed opinion.
I however think this probably reflects more on the programmers that are involved with the process than the process itself. Just like anything, the tool is only as good as the person using it. If you have a group of people who can generate a well designed system model using a few CRC cards or a dry erase board, and then get to writing code, you probably will have a well written program. But if the group of people can't even conceptualize the problem into some sort of design, then the code will end up being just like my instructor said "A whole bunch of mess"
Do those of you who have experienced XP in the real world find similar occurences?

[Tiger Scott]

XP does under-emppasize design- it has this concept of evolutionary design rather than big upfront design. You can read Martin Fowler's article Is Design Dead about how XP does its design.
Sanjay
[ February 19, 2002: Message edited by: Sanjay Bahal ]

[Ilja Preuss]

Originally posted by Sanjay Bahal:
XP does under-emppasize design- it has this concept of evolutionary design rather than big upfront design.

I am confused. How does evolutionary design, including techniques like test-driven-development and merciless refactoring, under-emphasize design?

[Ilja Preuss]

Originally posted by jason adam:
My OOAD facilitator, who leans strongly to the XP side, has found that the majority of the projects that he has worked on that utilized the XP process were pretty much a "license to hack".

I would rather call XP a "license to continuously improve the design". In fact it demands for it. Of course this needs knowledge and discipline; pair programming can help to improve both.

[jason adam]

Thanks for the article Sanjay. I actually read it several months ago, and it's what got me started learning more about XP, not to mention becoming a big fan of Fowler.
I agree with Ilja, I don't think that design in XP is under-emphasized, I think it's the tedious process of documenting your designs in UML diagrams that is pushed to the way side. That is what my question really revolves around. Do people who are actually implementing XP see the same behavior that I described above (code that is pretty much thrown together and hacked continuously), or do you actually use some sort of diagraming, albeit a very high level one that may be used just to spring board the development process.
At my current employer, there are meetings about meetings, and then meetings about what was discussed in the meetings, and then stacks of papers documenting the process, and by the time you actually start working on the project, everything that was discussed and documented is out of date, so you start back up again.
XP being the polar opposite of this "process", I could see how some people would use the label of being an XP operation, and just go willy-nilly with the whole thing just for the sake of having a new label.
How is it really implemented out there, does it work, what are some experiences? Theoretically sounds great, how is it practically?

[Rick Salsa]

This link might help. I find that those who really understand XP on our team use it effectively. Those you just sit down and begin to code with out a plan, goal or some story to go by are just hacking things up.
/rick
[ February 19, 2002: Message edited by: rick salsa ]

[Tiger Scott]

It is a matter of semantics- what is the meaning of under emphasis of design. The typical/conventional design process is lot of up-front design work and documentaion etc. But in XP you develop feature and design evolves.
..That is what my question really revolves around. Do people who are actually implementing XP see the same behavior that I described above (code that is pretty much thrown together and hacked continuously),...
XP promotes continous refactoring- In my experience it does lead to hacking. Once again one peson's hacking could be another person's design or refactoring.
Sanjay
[ February 19, 2002: Message edited by: Sanjay Bahal ]

[Ilja Preuss]

Originally posted by Sanjay Bahal:
It is a matter of semantics- what is the meaning of under emphasis of design. The typical/conventional design process is lot of up-front design work and documentaion etc. But in XP you develop feature and design evolves.

The "typical" process also somehow tries to freeze the design early on, whereas in XP you *never* stop designing. I wonder which one has an under emphasis on design...

XP promotes continous refactoring- In my experience it does lead to hacking. Once again one peson's hacking could be another person's design or refactoring.
Sanjay

So you say that regarding your definition of "hacking", it is a reasonable way to get a good design?

[jason adam]

Groovy, this is pretty much everything I was hoping to hear (though only hearing from a very small percentage of the population ). This all stems from the courses I have taken, and unfortunately I have not been able to move into the software development field quicker, still stuck doing Sys. Admin. junk. So I'm pretty much stuck with what I read and hear, and not experience
Anyways, the design classes focus on UML as a way to convey meaning of what a system is doing between colleagues and customers, but luckily my two instructors have favored XP over any other processes, so we haven't been totally bogged down with documenting everything in sight. It does feel like some of it is just "going through the motions", though I am sure there are some customers you might have that expect you to jump through the hoops.
I agree diagrams have their place, but only so far as to get the meaning across and not as the reference point to which you should always return.
I agree more that the code should be the design, and any disciplined developer should be able to produce well designed code without having to hover over a bunch of boxes and lines for hours.
Thanks for the discussion, please feel free to continue

[Doug Wang]

Judging from Martin's article, design is not dead but goes in a different way. Design should be implied in the following cycle:
(designing ->) coding -> refactoring(with testing) -> continuous integration
(Being in the extreme, Kent thinks coding itself is design.)
Furthermore Kent and Martin tell that codes and test cases are just what you call "document". Will we never need diagrams? What should be necessary document in an Agile process?

[shailesh sonavadekar]

please read martin's article abot new methodology. it gives comparision between bridge construction & software construction. in bridge construction , design is 15 % of project cost & rest is construction. but , in case of software construction , 50 % cost is design ( refrence to great Steve MCConnel ). so , I think " design is not at all dead "
Doug , in agile , Alistair is saying that people find it hard to follow disciplined proceess . so , the least disciplined process is going to be successful. big statement. he also advocates the ease development at the cost of productivity.
about documents , i don't think you can give away the documents.

I think Alistair explinas this , it will be great help.

[Doug Wang]

Originally posted by shailesh sonavadekar:
please read martin's article abot new methodology. it gives comparision between bridge construction & software construction. in bridge construction , design is 15 % of project cost & rest is construction. but , in case of software construction , 50 % cost is design ( refrence to great Steve MCConnel ). so , I think " design is not at all dead "

Yes, you are right. Agile approaches emphasize quality of design.

Doug , in agile , Alistair is saying that people find it hard to follow disciplined proceess . so , the least disciplined process is going to be successful. big statement. he also advocates the ease development at the cost of productivity.

I dont agree with you. Less discipline only means ease of execution, not likely sucess. Actually, in XP, there is much discipline, such as testing first, pair programming, continuous integration, etc. And XP is more likely to generate productivity.

about documents , i don't think you can give away the documents.

But when and which documents should we give? Or how to capture our design idea? Is code and test case good enough?
Ilja/jason,
How to refactor UI design? Since from Rob's recommendation, Constantine criticizes that Agile methods ignore UI design.
[ February 20, 2002: Message edited by: Doug Wang ]

[Rich Cohen]

XP is a collection of practices and principles. One of the principles is not to expend effort on a complete design before beginning construction of the system. If you consider only this one aspect of XP, then you might well describe XP as a "licence to hack."
But XP advocates much more than this one principle. Other XP practices work in conjunction with rapid, iterative, incremental implementations of a system to circumscribe the "licence to hack". (XP is a collection of principles and practices; it is not a methodology and does not dictate specifically how things should be done. So there can be variation in how different groups adopt XP. So anything below that sounds like a dictum of XP should be read as an example of an XP principle.)
One XP practice outlaws working beyond a normal work day/week. (Ok, so just hack during working hours.) Additionally, all coding is done in pairs. This does not preclude hacking, but does mean another member of the development team is working with you as you evolve your design and develop your code -- following your line of thought and your design decisions, asking questions and suggesting alternatives as the work progresses. Further, XP says that you always build unit tests for your classes. These are not practices I associate with "just hacking," but maybe you know more disciplined hackers than I do.
XP also says that you should "refactor mercilessly." One aspect of that is that when you need to extend a class, and the class implementation does not readily admit your extension, rather than "just add something that will work for now," you refactor the class so that your extension fits easily and naturally.
Because XP teams practice "collective code ownership," everyone can see everyone elses code. So if someone violates the team coding standard, that is obvious. If someone builds a bad abstraction, everyone is free to see it, discuss it, and refactor it. (Although the code is "owned collectively," that does not mean that the team doesn't discuss changes and use a source code management system. It just means that no code is hidden, and no one person is a procedural bottle-neck to fixing code that needs fixing or enhancing. One of the fundamental principles of XP is communication. So, of course, the team is expected to let each other know about significant changes and refactorings they make along the way.)
Earlier notes in this thread suggested that the practice of a continually evolving design might be considered to emphasize design, rather than deemphasize it. Good point! A key point about refactoring is that you are not randomly reimplementing a class. You are making incremental improvements to enhance the clarity and structure of your classes. Hacking says you never go back to fix something with more than chewing gum and duct tape. XP says that you refactor and clean it up when you need to fix it. One of the benefits of pair programming is that, while you might do the chewing-gum it if working alone late at night, working with a co-worker in broad daylight may encourage you to respect the agreed-upon team practices.
So, is XP a "license to hack"? Well, if by hacking you mean pair programming, building unit tests, continuously improving the design of your individual classes and your program, always trying to keep your code as simple as possible, and refactoring (at least a little) when you encounter existing code that is no longer clean and simple, then you can say XP is a "licence to hack".

[Ilja Preuss]

Rich,
nicely put!

[David Peterson]

Unfortunately people seem to pick up on the fact that XP is light on 'ceremony' (paperwork), but that doesn't mean it's light on discipline.
Far from it. It takes a great deal of discipline. Automatic tests are at the core of XP - if you're not writing tests for all your code, you're not doing XP. If you're not constantly refactoring (simplifying, removing duplications etc) you're not doing XP.
You get people saying "hey, we don't write documentation either so we must be doing XP". It's very annoying because it promotes this idea that XP is hacking. It definitely is not.
David

[jason adam]

Wonderfully stated Rich, and pretty much inline with what I understand of the process.
Still, my main question is still what is actually being done? Since it seems like several experienced individuals have jumped aboard the discussion, I'm hoping to get some concrete examples of how a project is approached. Is there a very high-level diagram that is started at the beginning and built from there? Do you use cards to quickly get the idea down and then start coding? Do you start each project in a similar fashion, or is each considered a blank slate and the group proceeds the most comfortable way for that project?
Again, trying to separate what is down on paper to what is actually relevant in the industry.

[Alistair Cockburn]

<<Agile approaches emphasize quality of design.<br /> <<<Doug , in agile , Alistair is saying that people find it hard to follow disciplined proceess . so , the least disciplined process is going to be successful. big statement. he also advocates the ease development at the cost of productivity.>>> <br /> I dont agree with you. Less discipline only means ease of execution, not likely sucess.>>

Doug's right here ... in Agile it also says that disciplined adherence to effective practices makes better (and disciplined adherence to ineffective practices makes worse).
Undisciplined is easier to set into motion... doesn't necessarily mean will produce better results. That's the trade-off inherent in the XP vs. Crystal comparison.