Saturday, September 30, 2006

The big three: Flexibility Extensibility Maintainability

[Time: 1 min 45 secs]

As we have said earlier, software is rarely ever made and forgotten. After the release, there will be change requests, there will be requests for new features, and bugs to be fixed. And why after the release, even when we are in the process of making software we have to interact with code that has already been written. It is with the goal of easing all of these, that we design software.

The design should enable flexibility, extensibility, and maintainability.

[Time: 9 mins]


  • What is flexibility?
  • Actions for change
    • Identify, Change, Test
  • Detractors of flexibility
    • Complex code
    • Lack of clear responsibilities for classes and methods
    • Unreadable code
    • Repetitions in code
    • Uncontained functionality
  • Design decisions that promote flexibility
    • DRY (Don't repeat yourself)
    • KISS (Keep it simple)
    • No tricks
    • Loose coupling
    • Encapsulation
    • Note: Minimize testing

[Time: 6 mins 25 secs]


  • What is extensibility
  • Actions for extensions
    • Actions for change, adding classes
  • Detractors of extensibility
    • Same as detractors for flexibility (ideally we want to extend the software by adding new classes and not modifying existing classes)
  • Design decisions that promote extensibility
    • Loose coupling
    • Assigning proper responsibilities
    • Proper use of inheritance and polymorphism
    • Design patterns


  • Maintainability is flexibility + extensibility + bug fixes + refactorings

  • All design idioms for flexibility & extensibility apply to maintaibility also. Besides these design factors, some process factors like having proper test cases, and good documentation also apply. But since we are focussing on design in this section, we will not take any process related issues.
  • Remember "maintainability" is the ultimate goal of software design

Note: This post was originally posted on my blog at

Thursday, September 28, 2006

Goals Of Good Software Design

What is object oriented design? What is it all about? What are it's benefits? What are it's costs? It may seem silly to ask these questions in a day and age when virtually every software developer is using an object oriented language of some kind. Yet the question is important because, it seems to me, that most of us use those languages without knowing why, and without knowing how to get the the most benefit out of them.

-- Uncle Bob

It's time we asked these questions. Let us start with the most basic of them all:

What are the goals of software design? 

In this section we will discuss the goals of software design and how object orientation helps us achieve those goals. 

Note: This post was originally posted on my blog at

Wednesday, September 27, 2006

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...


Monday, September 18, 2006

Networked Reciprocal Learning

Sometime back I read an interesting article which says that the half life of technical knowledge (period after which knowledge becomes obsolete) is reducing. A few decades back it was perhaps 10 years which has now come down to 18 months. This has significant implications for training and learning.

The most important implication is "no one knows it all". It is just impossible for a person to know everything in their field. Taking an example from the software industry, in 1996 when people first started working in Java, there were developers who knew all of Java, but as the platform started bulging it became increasingly difficult. Now it is possible to know only a part of the platform really well, and as the platform grows, keeping up with the latest information is even more difficult.

Maybe we need to change the learning and training paradigm. Instead of trainers, we need facilitators who are part of a reciprocating learning network. No one is only a learner or only a trainer. Learners probably are 80% consumers and 20% contributors, while facilitators are 20% consumers and 80% contributors. Everyone should ideally teach and learn in a continuous and informal manner.

To facilitate this, we need to change a few things. The first is "attitude". People need to change the attitude of wanting to be "taught" to taking a more proactive role in their learning. They must actively seek knowledge and mentors in the network. The network must consist of micro-mentors where everyone has strong skills in certain areas, and the network as a whole has sufficient knowledge to meet the needs of the community.

Such networks may actually satisfy the training needs of companies much better than classroom based training.

I think the Internet and new media such as blogs, podcasts, and webcasts, and educational technology holds great promise in helping us creat such networks. We can create a suppporting infrastructure using open source technologies, but more about that in another post... :-)

Monday, September 11, 2006

Personal Learning Environment

We're living in times where our knowledge and learning demands are growing at a rapid (sometimes ridiculously rapid) rate. I often find myself overwhelmed with the things that I have to learn to get my work done. The time has come, where we must take charge of our learning requirements. The traditional one size fits all approach just will not work in the current environment. Every person needs to specialize and generalize their skills in different areas. The one size fits all approach assumes everyone has the similar learning goals.

The need of the hour is a personal learning process. This image from Harold Jarche's website shows it very well.

Many thanks to Harold Jarche for the image.

Each one of us can customize this process and the tools to suit our individual requirements.

Quality control guru, Edward Demming, said "learning is optional, so is survival."