Defining Design Quality

Posted by Amr Elssamadisy on Apr 05, 2007

Sections

Process & Practices,

Architecture & Design,

Development

Topics

Design ,

Agile ,

Software Testing ,

Object Oriented Design

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.

• Older >