I've been thinking lately about good software design. It occurred to me that good design might contradict one of the XP principles: do the simplest thing possible. The problem is that good design is rarely the simplest thing that will work.
I disagree. More often than not (at least in Java, at least in my experience) the simple design is the better one. If you leave room for versatility and growth.. it benefits you more to have a simple design rather than a complex one.
I can think of countless times when I scrapped a complex code structure to replace it with something much more simple.. but much, much better. The problem is that simple and good isn't easy...
TrackBack URL for this entry: http://www.unix-girl.com/mt/mt-tb.cgi/509
This isn't an easy problem. Our current lead programmer seems to have a tendancy to pick wonderfully simple solutions to complex problems and then finding the most god-awful complex way to implement them (no, we can't get rid of him, but one of our designers did just purchace a rather nice rifle).
It seems like the key is to find a "just complex enough" solution to your problem that can later be made to do all manner of strange things that your client/manager/whatever will eventually want you to do with it, and then implementing it in a simple manner that can be extended in stages.
Or at least that's what's worked for me in the past.
#I wholeheartedly agree. In fact it takes discipline not to go off and generalize and get all complex, early. And I think the best days are the ones where you look at some abstraction you're built, decide that you overbuilt and don't really need all the complexity, and DELETE code.
Just the other day I went from per-entity Id classes, deleted them all and went back to using simply Strings. Why? Because nowhere in my tests was any such thing necessary in or to avoid code duplication. Which brings me to...
I have found religion and it is TDD. My conclusion about XP (all except pair programming) is that it's good because it's one of the best ways to support TDD. But TDD is the main thing. Everyone should at least sit down in a book store and read the first few chapters of Kent Beck's new TDD book.
#yea... simple is good... but not as good as uniformity... if you do something in a certain manner throughout a project, buyt once or twice completely reverse your programming principals it's going to cause a lot of confusion... if you use complex, but consistent, methodology it could prove easier to work with in the debugging process due to predictability (ex programmer george ALWAYS did function_blah() with his code... i bet thats whats messing me up now!) where as tight busts of colorfull code that differ from function to function in implimentation can get confusing (why couldnt ex programmer susan always return a positive value on an error instead of constantly oscillating between -1, null, and positive x???)
well. may be flawed, but theres my "i just woke up, rolled out of bed, and fell onto a weblog" logic :)
#Just my opinion, but it seems that consistency in design is part of simplicity in design.
#i would think: "usually, but not always" and different people have different meanings for thr word "simple" e.g: the fewest lines of code, the fewest number of functions (encapsulated programming anyone?) i'm not saying i agree... but... there are some brilliant, yet odd ducks out there..
#Simplicity does not include individuals who are pretentious and talk absolute bullshit about God knows what. Apok I am referring to you.
#good design = efficiency
#