You are here:

C++/Software Design


What makes for good software design?

This is a really open-ended question, isn't it? Somewhat like "What is the meaning of life?".

A short answer is difficult, but if we must have one, this is about as good as it gets:

"A good software design minimizes the time required to create, modify, and maintain the software while achieving acceptable run-time performance."

Elaborating a little more,

"Great designs:

   * Are easily modified by the people who most frequently work within them,
   * Easily support unexpected changes,
   * Are easy to modify and maintain,
   * and Prove their value by becoming steadily easier to modify over years of changes and upgrades."

Both from the essay "Quality With a Name" by James Shore
You can read it here:

Eric Steven Raymond in his book "The Art of Unix Programming" stated several principles which make for good design:

  1. Rule of Modularity: Write simple parts connected by clean interfaces.
  2. Rule of Clarity: Clarity is better than cleverness.
  3. Rule of Composition: Design programs to be connected to other programs.
  4. Rule of Separation: Separate policy from mechanism; separate interfaces from engines.
  5. Rule of Simplicity: Design for simplicity; add complexity only where you must.
  6. Rule of Parsimony: Write a big program only when it is clear by demonstration that nothing else will do.
  7. Rule of Transparency: Design for visibility to make inspection and debugging easier.
  8. Rule of Robustness: Robustness is the child of transparency and simplicity.
  9. Rule of Representation: Fold knowledge into data so program logic can be stupid and robust.
 10. Rule of Least Surprise: In interface design, always do the least surprising thing.
 11. Rule of Silence: When a program has nothing surprising to say, it should say nothing.
 12. Rule of Repair: When you must fail, fail noisily and as soon as possible.
 13. Rule of Economy: Programmer time is expensive; conserve it in preference to machine time.
 14. Rule of Generation: Avoid hand-hacking; write programs to write programs when you can.
 15. Rule of Optimization: Prototype before polishing. Get it working before you optimize it.
 16. Rule of Diversity: Distrust all claims for “one true way”.
 17. Rule of Extensibility: Design for the future, because it will be here sooner than you think.

and then goes on to elaborate on each of these.
You can read it here:  


All Answers

Answers by Expert:

Ask Experts




my primary areas of interest are generic and template metaprogramming, STL, algorithms, design patterns and c++11. i would not answer questions about gui and web programming.


about 15 years or so

post graduate engineer

©2016 All rights reserved.