Extreme Programming defines Simple Design as (in priority order) - runs all the tests - contains no duplication - communicates all intentions - contains minimum number of methods/classes The assumption of XP is that if you always mercilessly refactor your design according to those rules and the currently implemented requirements, it will work out well. The natural question is - does that work? I don't have the definitive answer, but I'd like to share a recent experience. As some of you might remember, I am at times working on a hobby project to try out new techniques and practices. I started it a couple of years ago with a friend to try out some XP practices - Simple Design, unit testing, refactoring. Last week, we revived it to bring it a little bit forward and try something new - acceptance testing, using the tool from http://fitnesse.org/ This is what we found out about: - the existing design is *bad*; responsibilities aren't distributed well, there are some forms of duplication we didn't notice at that time and many intentions aren't communicated well by the code, - as it is, we can't write acceptance tests for the code in an easy way; we need to refactor it to do so. In fact we discovered some of the above mentioned problems by just trying to write the tests. - we are still able to refactor the system with confidence as we go. That is because we do have the unit tests to give us confidence, because the confidence is increased by the new acceptance tests - and perhaps because the design wasn't *that* bad at all... So, following the rules of Simple Design didn't suffice for us - because we didn't know how to interprete them. We didn't know much about the kinds of duplication to look out for, we didn't know what intentions to communicate, our unit tests were of the wrong granularity and we didn't have acceptance tests (therefore in a way violating the first rule of Simple Design). So, wouldn't it have been better to start the project with more upfront design - class diagrams, interaction diagrams and the like? I don't think so. In fact, this was already the third attempt on the project, and this is the first time we didn't reach the point of "let us throw it away and start over" ofter just a few months. Everytime we tried to "guess" how the design should look like without getting immediate feedback from the code, it only got worse. So, for me the rules of Simple Design aren't sufficient - I still need to learn about all the principles of OO design to get a good design. But I almost always can connect those principles to one or more of the rules, so they are giving me a good "framework" to apply and learn about the principles. Your mileage my varry, of course...
The soul is dyed the color of its thoughts. Think only on those things that are in line with your principles and can bear the light of day. The content of your character is your choice. Day by day, what you do is who you become. Your integrity is your destiny - it is the light that guides your way. - Heraclitus
Thanks for sharing your experiences. I've always had a concern about XP that it really only works if one of your pair is Kent Beck (or Ron Jeffries or Robert Martin) or one of a relatively small number of OO gurus. Of course, big design up front will be equally doomed without good OO chops! One bad thing about BDUF is guessing what might be needed some day, a waste of brain power, coding time, CPU cycles, etc. I'm not talking so much these days about doing less design as deferring design until the "last responsible moment" right before indecision becomes a decision by closing off one of the options. This eliminates guessing about the future nicely.
A good question is never answered. It is not a bolt to be tightened into place but a seed to be planted and to bear more seed toward the hope of greening the landscape of the idea. John Ciardi
Francis Bacon: The men of experiment are like the ant, they only collect and use; the reasoners resemble spiders, who make cobwebs out of their own substance. But the bee takes the middle course: it gathers its material from the flowers of the garden and field, but transforms and digests it by a power of its own. Not unlike this is the true business of philosophy (science); for it neither relies solely or chiefly on the powers of the mind, nor does it take the matter which it gathers from natural history and mechanical experiments and lay up in the memory whole, as it finds it, but lays it up in the understanding altered and digested. Therefore, from a closer and purer league between these two faculties, the experimental and the rational (such as has never been made), much may be hoped.
Good work, Illja. Keep us posted . BTW, no puns intended:- experiment---> XP ----> ant ----->collect,use(tools,test)-----> Simple Design rational----->RUP ----->spider -----> spin cobweb ----> BDUF
Joined: Jul 11, 2001
It just remembered another reasons for why we are able to refactor the code with confidence: we now do have years of practice doing it! I think that is an important point: if you start your project doing BDUF and only late in the project find the need to refactor, both you and your code aren't accustomed to refactoring...
Joined: Jan 29, 2003
But the bee takes the middle course: it gathers its material from the flowers of the garden and field, but transforms and digests it by a power of its own.
If so, would writing ATs earlier and more frequently perhaps have helped to reveal a better design?
Well, as I already wrote, it has helped us to reveal a better design *now*, so I suspect part of the answer is probably "yes".
On the other hand, when we started we already were busy learning unit testing and refactoring (and later removing all the Singletons we introduced at the start :roll: ).
So I think the rules of Simple Design are a powerfull guideline for experienced developers. They don't make you a wizard if you don't have experience. For me, regularly reflecting about them helped me get experienced, but that might just be me (and constrasting them with other design principles certainly has helped, too). [ January 07, 2005: Message edited by: Ilja Preuss ]
The term "simple design" is in itself non-descriptive. In your case the design was TOO simple. Generally, use the simpleST design that works, even if it is a complex design. When using agile methods, that design will start very simple and get more complex as neede. With traditional techniques, the design will start overly complex and grow more convoluted all the time as people start putting in things to get around the unneeded complexities.
Joined: Jul 11, 2001
Originally posted by Jeroen Wenting: The term "simple design" is in itself non-descriptive.
Yes. The term Simple Design, on the other hand, is well defined in XP. See above.
In your case the design was TOO simple.
I am not sure it was simpler than it is now. I think I just didn't know how to make it simpler - I didn't know what to look for and what techniques to apply. It isn't easy to produce simple code. I am quite sure that it wasn't Simple. Simple code is testable, as by the definition. Our code wasn't.
I’ve looked at a lot of different solutions, and in my humble opinion Aspose is the way to go. Here’s the link: http://aspose.com