BT

New Early adopter or innovator? InfoQ has been working on some new features for you. Learn more

Defining Design Quality

| by Amr Elssamadisy Follow 0 Followers on Apr 05, 2007. Estimated reading time: 3 minutes |
A good design is elegant and simple - but elegance is in the eye of the beholder.  James Shore, in his book The Art of Agile Development, disagreed with this abstract concept.  In fact, he provided a very concrete definition of design quality: "A good software design minimizes the time required to create, modify, and maintain the software while achieving run-time performance."

This is a very non-traditional view of software design – in fact it has nothing to do with the organization of components within the system, class hierarchies, and all of the traditional things that come to mind when design is discussed.  

To get some insight into this point of view Shore took a look at the evolution of programming languages and the current popularity of Ruby:
In fact, our computers are so fast, modern languages actually waste computing resources. With an optimizing compiler, C is just as good as assembly language. C++, though, adds virtual method lookups... four bytes per method and an extra level of indirection. Java and C# add a complete intermediate language that runs in a virtual machine atop the normal machine. Ruby interprets the entire program on every invocation!

How wasteful.

With such waste, why is Ruby on Rails so popular? How is it possible that Java and C# could succeed? What do they provide that makes their waste worthwhile? Why aren't we all programming in C?
Shore then went on to assert that good design (not just software design) is the “art of maximizing the benefits of our tradeoffs”.  This led directly to the thought-provoking definition of design above: "A good software design minimizes the time required to create, modify, and maintain the software while achieving run-time performance."

If good design is dependent on the creation and modification of software, what then is great design?
Equating good design with the ease of maintenance is not new, but stating it this way leads to some interesting conclusions:

   1.  Design quality is people-sensitive.
If the object of good design is to minimize the amount of developer time, then an application that is easily built and maintained by a group of developers who know and understand java will be a good design.  The same application will be considered a very poor design for a group of C++ programmers.  The same design has different quality that is dependent upon the programmers writing and maintaining the code.
   2.   Design quality is change-specific.
Design quality being change-specific is nothing new.  That is good – this new definition doesn’t contradict what we already know – it adds to it.  There are two general ways to make designs of higher quality with respect to this aspect: generalizing ala’ tools like design patterns, and using tests and refactoring as change-enablers.  An interview with Erich Gamma is very informative when it comes to this trade-off.
   3. Modification and maintenance time are more important than creation time.
This, again, is nothing new.  We know that time spent in maintenance is much more than creation time of an application.  Add to this, in iterative development, modification happens during the initial creation of the application, and we have even more reason to focus on this issue.
   4. Design quality is unpredictable.
By the above definition, quality is really dependant on the team developing the software.  As the team changes, or evolves, then the design quality also evolves.  It is therefore unpredictable.  You really only know how good a design is by it standing the test of time and modifications.

So how useful is this?  If we can’t predict if a design is good or not – then what good is this definition?  If we tie this with the notion of programming as theory building as introduced by Naur, which says that there is a ‘theory’ to the code.  If you understand this theory, then you can easily and correctly modify the code.  Then, understanding the ‘theory’ of the code mitigates the unpredictability of point 4.  We can maintain the quality of the design if we maintain the theory of the design as the programming team evolves.

A draft of Shore’s book is currently available to the public for review. He gave us a definition of design quality that is thought-provoking by tying design quality to the people who are building and maintaining the application.

Rate this Article

Adoption Stage
Style

Hello stranger!

You need to Register an InfoQ account or or login to post comments. But there's so much more behind being registered.

Get the most out of the InfoQ experience.

Tell us what you think

Allowed html: a,b,br,blockquote,i,li,pre,u,ul,p

Email me replies to any of my messages in this thread
Community comments

Allowed html: a,b,br,blockquote,i,li,pre,u,ul,p

Email me replies to any of my messages in this thread

Allowed html: a,b,br,blockquote,i,li,pre,u,ul,p

Email me replies to any of my messages in this thread

Discuss

Login to InfoQ to interact with what matters most to you.


Recover your password...

Follow

Follow your favorite topics and editors

Quick overview of most important highlights in the industry and on the site.

Like

More signal, less noise

Build your own feed by choosing topics you want to read about and editors you want to hear from.

Notifications

Stay up-to-date

Set up your notifications and don't miss out on content that matters to you

BT