Tracking change and innovation in the enterprise software development community
QCon London 2010!
March 10-12, 100
Speakers, 80 sessions,
"THE" team leads and,
architects conference.
Free Book Offer
SOA Demystified
$40 Value
Scaling Scrum
in the enterprise?
ScrumWorks Pro
can help.
Start a trial today
Posted by Mike Bria on Jan 29, 2009
It's not news that at the heart of successful software projects (and, frankly, fulfilling software careers) is good design. Also not news is that defining what "good design" really means has been at the heart of an infinite array of debates, papers, talks, books, discussions, and more for ages. To help, J.B. Rainsberger and Scott Bellware offer some advice to follow until that one true definition comes along.
Recently, well-respected Agilist and TDD-thought-leader J.B. Rainsberger was commenting on how over the years he has "witnessed a number of attempts to develop a complete, constructive definition of good design". His primary observation and personal revelation:
Some people lament the lack of a complete, constructive definition of good design. I don’t, and today I finally articulated why I don’t think we particular need to worry about this.
He continues with a disclaimer that he doesn't disagree having a "clear test for a design's 'goodness'" would be a useful thing (with examples as to why), but then expands on why he's not terribly concerned that we may not yet have [in this editor's words] "that one true way". He points to his experience, to what he thinks we do have to help us optimize our chances of ending up with a "good design":
In the past ten years I have learned some incredibly useful things about design:I have learned these things through my own practice, through pairing with others, and through observing other programmers at work. I find it more significant to note that even with only these three observations, we have improved the value of software design considerably.
- When programmers write design tests, they tend to find more of their own defects more quickly, which reduces the overall cost of realizing their design.
- When programmers duplicate code, defect rates increase, and when they reduce duplication, defect rates decrease.
- When programmers first start to change unfamiliar code, they tend to start by clarifying unclear names in the code: variable names, method names, class names. This practice helps them change code more safely and less expensively.
J.B. closes with a thought about what he often uses to identify a good design, "I get by with the Miller Test: I know it when I see it."
Interestingly, one of the key themes in what J.B. is saying has to do with an idea that for a design to be good, it should "look good" to someone new to it; (paraphrased) "..unfamiliar code? Clarify names so you can better understand it..", "I know it when I see it". Not to stretch J.B.'s message beyond what he means, but some might take this to imply that a good design will at a minimum be one which is "easily learned", and idea written about recently by Scott Bellware. In his words:
The essence of "good design" is it's ability to be absorbed by a human mind. Design is "good" when it can be easily-learned.
...
Good design is about knowledge. We wrap it up in all kinds of terminology, but in the end it's about making smallish bits of software that are easy to understand on their own, and that fit together exquisitely to make things bigger than themselves, and that can still be as easily understood.
Bellware goes quite deeply into how the term "testability" relates to the idea of good design, but not necessarily in the way it is often used. He stresses that code's "testability" is not about "whether it can be tested", but rather if it "is [currently being] easily tested", and that "testing" is all about learning:
Remember, testing is about making observations, and observations are about learning.
...
If it's hard to set up an object in order to learn what it does and whether it does it right, then you've probably got a poorly-designed object. This suggests that you can use test code to prove that you've got the right design. And this is what testability means.
...
No matter how good I become in object-oriented design, the only proof that a design is good is [example/test] code that proves concretely that I have achieved the highest level of ease of setting up an object for use.
So, as J.B. points out, unambiguously defining "good design" may just be one of those golden carrots; it's always one step in front of us, no matter how many steps we take forward. But also as he highlights, and as Bellware seems to suggest, there are tools we have right at our disposal today to help guide us towards designs that keep us productive and keep us happy, enjoying our day jobs as programmers. What do you think?
Consolidation and Virtualization Are NOT Enough: The Case for Non-x86
Technical Debt and Design Death
VersionOne is recognized by Agile practitioners as the leader in Agile project management tools. Companies such as Adobe, BBC, CNN, Dow, HP, IBM, Sony and 3M have turned to VersionOne to help deliver greater value to their customers.
I don't have a link handy where some luminary says that designing is, at heart, about learning, but I agree with that idea. And here we agree that a good software design is - among other things - better when it is easy to learn.
I think we can conclude that one of the ways we can design code is by test-driving it -- tests help us learn where our design needs to go, and when writing a programmer-test becomes hard, that is a signal that we can learn from.
"Design" is one of those concepts that will always be impossible for everyone to come to consensus on what it is. However, I believe that while it is important for someone to learn from a "good" design, the complementary point of a design is to clearly communicate ideas. Without clear communication learning becomes a real challenge.
Any design that is in some way incomplete, vague or ambiguous can quickly lead to a break down in communication, and, as an outcome, allows for poor quality in implementation, maintenance and tests. This is why it is so important that software developers and architects not only have the technical chops but also have training to clearly communicate complicated ideas both in verbal and written form.
Clearly communicating design is no easy task for any sizable system, but it should be seen as a primary goal for any project to become truly successful.
To me, Robert C Martin summons up what good design is (www.objectmentor.com/resources/articles/Princip...).
From the conclusions;
"... structure of classes and packages that keeps the software application flexible, robust, reusable, and developable."
Well said, my friend C. Keith.
As for your second assertion (pun intended) about learning from the tests (what I personally like to call "listening to your tests"), the post by Scott Bellware also stresses that point. Albeit, he does appear to go to great lengths not to explicitly say "test-drive" or "TDD", which I did find interesting. ;-)
Cheerios
MB
Yes, but those are properties of good design, and not guidelines for achieving those properties. The Four Elements of Simple Design are guidelines for achieving those properties and, in my mind, sufficient for most current purposes.
I've found that a common property of most good designs is that they minimize dependencies. This is a property which is quite easy to measure and to strive for.
I believe in the statement that good design is a design easy to learn. In addition, when I make a design, I like to challenge and also ask others to challenge it from different perspective, if I find it's easy to persuade myself and other challengers, it is very probably a good design.
A concrete design's quality cannot be measured with "hard facts" if the requirements are not taken into account. I can create the most beautiful design, alas, it does the wrong thing altogether. It's beautiful, but bad nevertheless.
My universal properties of good design are (from the top of my head):
- names and terms wisely chosen
- provokes very few misunderstandings
- easy to communicate
- concepts are clearly separated by concerns and not wildly interconnected
- often, symmetry and beauty of shape (Gestalt) are indications of good design. For example, you can very often identify code that stinks only by its shape, without exactly knowing what it does.
Good design has a lot to do with aesthetics. Not measurable, of course. That's where experience comes in. "I know it when I see it" fits here nicely.
Jim's take:
jamesshore.com/Articles/Quality-With-a-Name.html
Well worth a print out, read, and posting on the team room wall.
Brian Marick takes us through a quick tour of the most important values and challenges to adopting Agile successfully (they aren't the typical challenges and values we hear in the community).
The line between development and architecture is tricky. Does it exist at all? Is an ivory tower actually needed? There's a balance in the middle, but how do you move from developer to architect?
The word 'authority' sometimes produces an allergic response in hard-line agilists. Freedom and authority – both are bad if misused and both are good if used in right spirit for a noble cause.
"Getting Started with Grails" brings you up to speed on this modern web framework. Companies as varied as LinkedIn, Wired, and Taco Bell are all using Grails. Are you ready to get started as well?
Those familiar with only ITIL V2 often scoff at the thought that ITIL could serve as a governance framework for SOA. With ITIL V3, the focus of the framework shifted towards service-orientation.
SpringSource CTO Adrian Colyer discusses AspectJ, SpringSource's dm Server and tc Server products, OSGi and Scrum.
Heroku's Adam Wiggins talks about Rails, Background Jobs, Add-Ons, Ruby, and how Heroku manages to work around Ruby's inefficiencies using Erlang and other languages.
For Grady Booch the foundation of a good architecture is patterns, SOA being just one of many patterns. In this Second Life presentation, Booch attempts to bring more clarity on what architecture is.
9 comments
Watch Thread Reply