On Practices in Design: Modular Design (Modularity)

Recently, I read an article on Java Modularity on InfoQ (Modular Java: What Is It?) and forced me to revisit my notes on modularity from the 1990s. As expected, every bit of the principles espoused then are applicable now. The following is what I learned then.

In Modular design, software is divided into separately named and addressable components, called modules, which are integrated to satisfy problem requirement. It implies a system decomposed into “natural” components that can be developed and maintained independently.

Many researchers are advocating the benefit of using a modular design approach. Bertrand Meyer (in his book Object-Oriented Software Construction) came up with a set of criteria to characterize modular design. These criteria provide a first step in formalizing the design practice of modularity.

Meyer’s Five Criteria for achieving modularity:

• Decomposability - the facility with which a design method helps the designer to decompose a large problem into sub problems that are easier to solve.


• Composability – the facility with which a design method ensures that program components (modules), once designed and built, can be reused to create other systems.


• Understandability – the ease with which a program component can be understood without reference to other information or modules.


• Continuity – the ability to make small changes in a program and have these changes manifest themselves with corresponding changes in just one or very few modules.


• Protection – an architectural characteristic that will reduce the propagation of side effects if an error does occur in a given module.

From the above criteria, Meyer suggests five basic design principles can be derived for modular architecture:

1. Linguistic (such as Java) modular units


2. Few interfaces


3. Small interfaces (weak coupling)


4. Explicit interfaces


5. Information hiding

Effective modular design practice always encompasses the well-understood software development principles such as Abstraction, information hiding, and Functional independence. The concepts of abstraction and information hiding help to focus on the relevant element during design and development. The main focus of functional independence is to design modules that serve one function and limit excessive interaction to other modules. The two methods that are used to measure the independence of a module are Cohesion and Coupling. Thus, the main goal of modular design is to minimize Coupling and to maximize Cohesion.

Since Modularity is a process of creating or structuring a system in to manageable size of modules, it may suggest that creating many modules to be an optimal solution. But, there are some principles to be considered here:

• On what bases is the modularization effort to be conducted, i.e, by functionality or by size?


• When do we know we have crated optimal modules for the solution?


• What are the procedures to achieve modularity?


• Is the process reversible?


• What properties are available to measure the conformance of the modules with?

In order to answer the above questions, I suggest the use of SOLID principles from Robert Martin (Agile Software Development, Principles, Patterns, and Practices). These principles provide two aspects: the first one is that they help in the development activity to attain good design and the second aspect is to evaluate an existing design or during a design review activity.

I will continue to revisit my notes and share the interesting ones on the up coming posts.

Currently Reading: What Got You Here Won't Get You There: How Successful People Become Even More Successful by Marshall Goldsmith and Mark Reiter.

On Treating Others

I am in a software development business and working with immensely talented people. I have been in this business for 15 years and worked for four companies - the talent pool always seems to be the same. As I see it, these talented people come with exceptionally different behavior - some of them do have an elephant-like ego; some of them modest, a few are real geeks that seem to be oblivious to their surrounding, and others ... ok, you get my drift. Working with these talented people taught me a lot on how to respect differences and be able to work with each other. I hope this lesson will stay with me forever.

Treating people require basic decency and that should be applied to all people regardless of their position in the company hierarchy or by their popularity amongst other people. If you work with a full-time employee and a contractor (temporary employee with short period of contract) you should see both of them the same way. Both of them are human beings and both of them do have feelings and emotions - it is unnatural to consider the contracto to be different or as somebody to be pushed around.

Early in my career, I was working for a consulting company. I was assigned to different client sites working on specific projects with my own colleagues or working embedded in the clients' development teams. At that time, I was having back pain that was bothering me - the pain was unbearable so I contemplated to have surgery. I told my my colleagues from the client company and they felt my situation. Some of them were very compassionate and even helping me looking for the right doctor. ultimately, the news reached to the team manager. One day when I was about to go home at the end of the day, I met the manager in the lower deck of the parking lot while he was smoking cigarette. He stopped me and asked me when I was going to have surgery. I was sure I did not discuss it with him since I did not make the final decision yet. At the beginning, I was very happy that he was concerned about my situation - so, I thanked him for being concerned. Before I finished my sentence, he waved his hand to signal me to stop and he said he does not care about my surgery. He went on to say that his concern was to get appropriate replacement. Wow - the disparaging hand wave and the words following after that got into me. It was a blow - I went quietly (and probably shaking my head) to get my car on the upper deck (lucky him I did not park my car on the lower level:-) ). How did the lively and seemingly nice guy turn out to be so insensitive? Do not get me wrong - I am not being a cry baby and I understand the situation he had to deal with. But, was this the right way? Would he treat full-time employees the same way?

The moral is to treat everybody with respect - recognize that we are emotional animals. Actually, We all need to be emotionally intelligent so that we can work with others in the new and continuously changing world. Having an emotional intelligence is one of the main qualities for a leader and it all starts with treating people right. We all do have strengths and weaknesses - working in a team of people requires understanding each other well. Diversity in behavior, culture, interest, and other traits should not be seen as a challenge but as an opportunity. Opportunity that can take us all to a different level; opportunity that can bring about our survival best - it is a healthy relationship to have.

Currently Reading: Outliers: The Story of Success by Malcolm Gladwell

P.S.: I did not go through surgery - I learned to live with back pain via physical therapy. It was not affecting me for a long time other than occasional hick-ups here and there.