• Post Reply Bookmark Topic Watch Topic
  • New Topic
programming forums Java Mobile Certification Databases Caching Books Engineering Micro Controllers OS Languages Paradigms IDEs Build Tools Frameworks Application Servers Open Source This Site Careers Other Pie Elite all forums
this forum made possible by our volunteer staff, including ...
Marshals:
  • Campbell Ritchie
  • Jeanne Boyarsky
  • Ron McLeod
  • Paul Clapham
  • Liutauras Vilda
Sheriffs:
  • paul wheaton
  • Rob Spoor
  • Devaka Cooray
Saloon Keepers:
  • Stephan van Hulst
  • Tim Holloway
  • Carey Brown
  • Frits Walraven
  • Tim Moores
Bartenders:
  • Mikalai Zaikin

Is Simple Design sufficient?

 
author
Posts: 14112
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator
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...
 
(instanceof Sidekick)
Posts: 8791
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator
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.
 
Ranch Hand
Posts: 3404
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator


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

regards
 
Ilja Preuss
author
Posts: 14112
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator
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...
 
Stan James
(instanceof Sidekick)
Posts: 8791
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator

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.


Be The Bee!
 
Sheriff
Posts: 7023
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator
Ilja,
Do I understand correctly that you began writing ATs only after a long period of development?
If so, would writing ATs earlier and more frequently perhaps have helped to reveal a better design?
 
Ilja Preuss
author
Posts: 14112
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator

Originally posted by Dirk Schreckmann:
Do I understand correctly that you began writing ATs only after a long period of development?



Yes, correct. (You can find the tests we do have for now at http://bloodball.sourceforge.net/ )

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 ]
 
Ranch Hand
Posts: 5093
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator
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.
 
Ilja Preuss
author
Posts: 14112
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator

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.
 
Don't get me started about those stupid light bulbs.
reply
    Bookmark Topic Watch Topic
  • New Topic