Skip to main content

Goals of good software design

I have started publishing the section on Object Oriented design, and this has led me to ask some very basic questions of myself:

What are the goals of good software design?

Here are some points that come to mind:

1. Flexibility:
We may have to change the way in which certain things work. The design must be able to accomodate these changes with minimum effort.

2. Extensibility:
The software will need new features. The design must be able to accomodate them easily. Ideally we must be able to add new stuff by adding code and not by modifying existing code, because modifying existing code may break stuff that was already working.

3. Maintainability:
maintainability = Flexibility + Extensibility ?
Perhaps, but also important for maintainability is being able to understand the code. Which can be achieved by assigning appropriate responsibilities to classes, and not abusing inheritance.

These are common, but are there oher goals?

I came accross an article on the net that suggests that the design should be appropriate to the skill level of the team. That is, we should avoid using complex language features if the team in inexperienced, because they may not be able to maintain the code easily. I think this is slightly controversial. Would it not be better to use the complex features (I am assuming that their usage will bring significant benefit), and educate the team on how to use them?

How about Robustness. Can design influence robustness, or is it something that is attributed more to the process (like having a suite of unit tests, etc)?

Where does "Time to deliver" figure? Should it influence design decisions?

Is there anything else that I am missing? 

Will appreciate responses, questions, comments, suggestions, and the like from all my readers.

Notes: This text was originally posted on my earlier blog at
Here are the comments from the original post

DATE: 09/29/2006 05:24:59 AM
It's interesting that you should mention "Time To Deliver". I have seen it affect the design on many projects. When there is sufficient time developers create complex design and when deadlines are really close, the design can get quite crappy.

In my opinion both violate the law of appropriate design.

AUTHOR: Amol Chaudhari
DATE: 10/04/2006 12:47:57 PM
Hi Parag,
i think, in our last discussion we forgot the two most important design goals.
1. Correctness : the software should exactly do what it is supposed to do.
2. Robustness: the software should be fault tolerant. it should quickly recover from the unexpected situations.

DATE: 10/04/2006 06:24:43 PM
Hey Amol,
Interesting points. Any thoughts on how we can design a system for correctness and robustness?
Let's take a starting point:

Robustness is how stable a software system is when it runs for a long time, when the user does funny things with it, when the load increases. Many things like memory and resource usage, gracefully handling exceptional conditions, the ability to not let users do incorrect things and many more go into making a software robust. Now taking this as a cueue, can you come up with design decisions that will improve robustness.

Correctness: Does a software do what it is supposed to do? Again this means that the developers have followed the functional specifications. This may not have anything to do with design, but more to do with understanding the clients requirments, not assuming anything, preparing a good functional specification, or user stories, and following them properly. Even some Agile techniques like immediate feedback, and having a client onsite go a long way in achieving correctness.


AUTHOR: rahul saxena systems scit
DATE: 01/19/2007 08:40:48 AM
this is a great idea.but i think being a student that cost constraint will also come while designing a system because we design what the user wants but after making it if cost exceeds then the repo and work,time resources everything goes designing as per cost is also one

DATE: 01/19/2007 10:27:49 AM
A good way to ensure that we do not over engineer a system, is to follow the Agile principles of iterative design and "do the simplest thing that works". Even though many purists still like the "heavy up-front architecture" approach, I have found the Agile approach to be far more effective.


DATE: 07/14/2007 09:17:08 AM
I have recently got my first taste of software design.The trickiest part that I identified was assigning responsibilities to the class.
That was because i directly jumped on identifying classes rather than the objects and their responsibilities.
Even though working with object oriented language and framework i violated the very first rule of Object Oriented Design, "First Identify the Objects in the system".
Am still in process of designing "Robust" and "Flexible" design and this blog definitely helps me gain more insight on the concept.
As per my observation, most common mistake made by software professionals is to design as per convenience rather than design for extensibility and flexibility.
This leads to constraints in the system and also quality disaster.
People debate that with high preesure deadline it gets difficult to design a good system.
Thats still remains an open topic for discussion.

DATE: 07/15/2007 08:07:30 AM

You mention that identifying objects and their responsibilities was more important than identifying classes. Can you elaborate a bit more on that.

I agree, designing for convenience usually does not produce good design. I am of the opinion that a good design is "appropriate". A design that is geared towards convenience can make it very difficult to extend, maintain, and change the system.

However when designing for flexibility and extensibility it is important not to go overboard. Because then we may build flexibility for parts that do not need it, leading to very complex design that is hard to understand.

This will probably be the topic of another post, but there are subtle differences in how to design good API's frameworks, and application logic.

The effect of time pressure is also another consideration, but I think that "appropriate design" should balance all these factors.

DATE: 07/16/2007 07:04:53 PM
What I meant by identifying objects was identifying the real world entities. If we are designing an e-Learning solution, Course, ILT Offering, WBT Offering ,Classroom, Instructor , Packages are the objects in the system. We identify common characteristics and relationship between them.
E.g Offering and Course has a one to many relationship and an Offering contanis a Course. Similarty ILT Offering , WBT Offering is a type of offering.
After defining such relationships and association we get a fair knowledge of how objects interact and then we can model them into classes.
I may be missing the links in between.Am still budding.:).

DATE: 07/17/2007 05:41:33 AM
Yes, yes, that's absolutely fine. In fact that is the way to go about things...



Unknown said…
I really like his flexibility with deadlines, attentiveness, creative inputs, and motivating personality. san diego landscape architect

Popular posts from this blog

Running your own one person company

Recently there was a post on PuneTech on mom's re-entering the IT work force after a break. Two of the biggest concerns mentioned were : Coping with vast advances (changes) in the IT landscape Balancing work and family responsibilities Since I have been running a one person company for a good amount of time, I suggested that as an option. In this post I will discuss various aspects of running a one person company. Advantages: You have full control of your time. You can choose to spend as much or as little time as you would like. There is also a good chance that you will be able to decide when you want to spend that time. You get to work on something that you enjoy doing. Tremendous work satisfaction. You have the option of working from home. Disadvantages: It can take a little while for the work to get set, so you may not be able to see revenues for some time. It takes a huge amount of discipline to work without a boss, and without deadlines. You will not get the benefits (insuran

Testing Groovy domain classes

If you are trying to test Grails domain class constraints by putting your unit test cases in the 'test/unit' directory, then your tests will fail because the domain objects will not have the 'valdate' method. This can be resolved in two ways: Place the test cases inside test/integration (which will slow things down) Use the method 'mockForConstraintsTests(Trail)' to create mock method in your domain class and continue writing your test cases in 'test/unit' What follows is some example code around this finding. I am working on a Groovy on Grails project for a website to help programmers keep up and refresh their skills. I started with some domain classes and then moved on to write some unit tests. When we create a Grails project using grails create-app , it creates several directories, one of which is a directory called 'test' for holding unit tests. This directory contains two directories, 'unit', and 'integration' for uni

Some thoughts on redesigning education

Some time back I read a blog post on redesigning education. It asked some very good questions. Stuff which I had been thinking of myself. I left my thoughts on the blog, but I would also like to start a conversation around these ideas with those who read this blog as well. I would like to know what other people think of the issue of redesigning (college) education. I have often thought about how college education can be improved. To answer this question, we first have to ask a very basic question. What is the purpose of education? To me, we need education for 3 things: To learn more about the world around us To lead positive constructive lives To earn a good living / fulfill our ambitions I think education has to a large extent evolved to fulfill #3 (with a bias towards earning a comfortable living). The semester system, along with multiple choice tests, and grading, has made our education system into an assembly line. Students are pushed into the assembly line, given classes, admini