On Software Quality Factors

Software Quality can be looked at from different angles in software development. These quality aspects manifest themselves at different situations and usually in combination. Some of the quality factors are listed below – these are usually referred to as software ‘ilities’ (based on the last five letters of their names). Some people argue against paying attentions to such factors as all of them may emerge in software development if the project development team uses the proper engineering principles. My take is that these factors provide conceptual clarity on the aspects of software quality at least at the higher level. I used the IEEE definition of these quality factors.

Reusability: The degree to which a software module or other work product can be used in more than one computing program or software system [IEEE]. It is the ability of a component/module to function and integrate in more than one environment. It is always manifested in and is considered as characteristics of high quality software. To achieve this quality, component or modules should be designed and implemented so that they can be reused in many different systems.

Maintainability:The ease with which a software system or component can be modified to correct faults, improve performance, or other attributes, or adapt to a changed environment [IEEE]. Maintainability provides a way of measuring the ease with which a program can be corrected if an error is encountered, adapted if its environment changes, or enhanced if the customer desires a change in requirements.

Flexibility: The ease with which a system or component can be modified for use in applications or environments other than those for which it was specifically designed [IEEE]. This concept encompasses the hardware, software and software combination in using a system. It is the effort required to modify an operational programs when environment of the system where it is running is changed.

Testability: The effort required to test a program to ensure that it performs its intended function.

Extensibility: It refers to the ease with which a program or module can be adopted with newer requirements with out affecting the existing one. It is the ability or property of a module that allows changes in many aspects such as performance, functionality, etc… within the same existing framework while retaining partial or complete compatibility among systems that belong to the same framework. Extensibility like other qualities can be achieved in varying degrees. An extensible system allows easy addition of new designs in an exiting one.

Related Post:

On Practices in Design: Modular Design (Modularity)

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.

On Favoring ‘Why’

I assume most of you, as a student, studied the 7 Ws – when, what, why, who, where, whom, and how (funny, the last one does not start with W). We have been using all these question formatters all our lives – but, have you ever favored one over the other?

Last August, I went to Ethiopia (I am originally from there) and did get a chance to catch up with my friends and relatives. I was out of the country for close to two decades. Eager to know about my life in the US, they have asked me different kinds of questions such as how is life in the US? How I overcame homesickness? But, one of my friends that I grew-up with asked me why I chose to live in the US. Why I did not come back to Ethiopia after my studies in the UK? This question took me off-guard.

‘Why’ is always fascinating to me and also, I assume, to other people especially kids. If you have kids, you know what I am talking about. Let’s see some scenarios on where we use ‘why’ and how crucial it is. Suppose, at work, some kind of change is to be implemented that may impact many people. If you are the leader of change, you should have a conceptual clarity on the need for the specific change and be able to communicate the reasons to those people affected by the change. When you are communicating the need for change, start with the ‘why’ of the change. People more often start with the ‘what’ of the change and get directly to how the change is going to be implemented. People, especially professionals, crave to know the impetus for change. Once they understand the reason, it will be easier for them to go along with the change or even to participate in implementing the change. If they are part of the change process, that means they owned the change. Remember, people support and stand by a solution that they have contributed to or helped create. For this to happen, it all starts with understanding the ‘why’ of the change.

Toyota uses the ‘Five Whys’ (5 Whys - Wikipedia, the free encyclopedia) approach to get to the bottom of a problem – root cause analysis (RCA). I found this excellent example involving Jeff Bezos of Amazon finding a root cause of an accident. He only asked few questions (whys) to get to the bottom of the incident and of course to the solution - see Jeff Bezos and Root Cause Analysis.

There are many cases and scenarios where we can discuss the benefit of answering ‘why’ – but, I hope you get the idea. The point is - in order to answer the ‘why’ of something, you need conceptual clarity. Answering ‘why’ needs thorough thinking and clarity in your reasoning. If you do not have any clarity in your answers, you should expect more questions to follow. Watch out of people that provide a quick and closed answer for a ‘why’ question. Such answers as – ‘Because I want to’; “It is not a democracy’; ‘Because I saw it in my dream’; and so on are very shallow. If you have a boss that is not capable of answering your why questions – run away from him/her.

I threw or blabbered some ‘wording’ to my dear friend to the question that he asked me - why I chose to live in the US. I realized how difficult is to answer the ‘why’ question without conceptual clarity. I also wonder how good all the answers were to the other questions from my family and friends - thinking that I might not answer the 'why' question.

Why do not you try to ask yourself some kind of why question – like, why do you choose to work for the company you are working for now? Are you sure of your answers?

Currently Reading: Pragmatic Thinking and Learning: Refactor Your Wetware (Pragmatic Programmers) by Andy Hunt.

On Incredible India

I just finished my second visit to India – we have two teams in Kochi (Cochin) and Bangalore. Even though the second time, some of the things that surprised me last time did surprise me again. I do not think seeing the whole family (up to four), including kids as young as months old, being on the same motor bike in the crowded streets pushing and shoving with all kinds of vehicles is a sight that one can get used to.

The streets are as crowded (may be worse) as before - pedestrian, autos (three wheelers), scooter, small cars and big cars still walk or drive aggressively. I do not understand why people are not driving orderly – even on a single lane people seem to enjoy crossing lanes in and out. I plan to watch my Indian colleagues how they walk – in a straight line or in a ziz zag. I might get the answer from there. I believe most of them are driving fast because they are in a hurry – if that is the case, their sense of urgency is understandable. There is also the noise factor – ‘driving by ears’ seems to be the necessary skill by drivers to be on the street. Drivers continuously use their horn to signal each other.

It seems everybody thinks that traffic accidents are to be seen as a risk of doing business. Accidents do happen - last time I visited, I witnessed an accident between a motor bike and a car. I did not stay long to learn about the consequence. Even in my current stay, in one of the offices I visited people were wearing the black band on their shirts. I learned later, one of their colleague’s spouse was killed in a car accident.

Apart from the ‘usual’ still India amazes me – the potential the country holds seems to be immense. Cities are full of people – all these people, what can they achieve? I believe, the current trend of utilizing the knowledge workers in the IT industry is not going to be enough to lift India to a different level. I am no economist but seeing the excesses and the poverty level tells you that India needs to do more – a lot more.

So, where to India? How fast can you move?

Are your people only aggressive on the streets? Will they take you ahead to the future the way they drive on the streets?

Do your children work to bring you to the next level with the same kind of sense of urgency they show on the streets?

The future is to be seen – I wish this country to be prosperous and lifting the beautiful, the modest yet poverty stricken lot with her. I love the people, the culture, the food, the music, and a lot more. Both of my visits were enjoyable – I continue to admire the beauty of this country.

Good Luck India!

Currently Reading: Made to Stick: Why Some Ideas Survive and Others Die by Chip Heath and Dan Heath.

On Component Interface, Specification, and Contract

Component Interface is a collection of operations that are used to specify services of a component. It is an abstraction of the behavior of a component that consists of a subset of the interactions of that component together with a set of constraints describing when they may occur. The interface describes the behavior of a component that is obtained by considering only the interactions of that interface and by hiding all other interactions. The description of a component interface consists of a signature part, describing the services provided by a component, and a behavior part, describing the component’s external behavior. Each operation has zero or more input and output parameters and a syntactic specification associates a type with each of the parameters including a return type.

The specification of a component is different and composed of many parts. Defining which interfaces the component will offer is just part of the whole component specification. Components can implement (export) one or more interfaces, called provided interfaces, and they can also use (import) interfaces, called required interfaces, from other components. The component interface is used both to implement the services and to describe the services so that to allow clients to find suitable services and to understand their purpose, functionality, usage and restrictions. In short, the interface defines every thing the client needs to know. An interface does not specify how implementations of this interface must interact with other components to fulfill their responsibilities; that is defined in the component specification.

While an interface defines a set of behavior, a component specification defines an implementation and deployment boundary. By specifying a set of interfaces that must be supported, a component specification defines the total sum of capabilities of any component created at run time from the implementation. This component specification can also define how the implementation must interact with other components. Knowledge of such interactions does not form part of the interface specification and so cannot be known directly by the client. We define these interaction constraints somehow in the component specification. Behavior is defined as a set of interfaces and a component specification is realized as a component implementation. The basic goal of component specification is to create a set of models that collectively describe externally visible properties of the component and constraint that are applicable to the proper implementation of the component. This goal makes component specification the ultimate guide for use of the component by clients, and for proper implementation of the component by implementers. Clients will pick and choose components based on the component interface. Component implemented based on a specific component specification should exhibit the same behavior regardless of who implemented it, what language is used to implement it, and in what environment it is installed.

Since components can implement (export) one or more interfaces and they can also use (import) interfaces from other components, at a minimum, component specification should provide a contract that states both the services a component offers and the services that it requires in fulfilling its commitments. Contract is mainly composed of three aspects: pre-condition, post-condition and invariant. Pre-condition is a condition that a client must be sure is true; otherwise, it is not legal for the client to use the service. Post-condition is a condition that should become true when the service is executed. Invariant is an observable property that does not change throughout the component’s life-time. Precisely, an invariant property is a property that always has the same value whenever the property is inspected.


Related Blog: On Software Component

Currently Reading: Confessions of an Economic Hitman by Perkins John

On Software Component

The early promises of object-oriented technology to provide reusable software elements did not bear fruit as expected. One of the main reasons for the failure is that objects are too fine grained for large-scale reuse efforts. In order to be reusable optimally, objects need to be coarse-grained in the services they provide and should have a published interface of what services they provide. One of the practices that gained wide spread acceptance in the software development industry through object technology is the practice of reuse using design patterns. Patterns embody accumulated knowledge about proven reusable design elements for software development. The use of design patterns has improved the quality of software and reduced the cost of developing software in object oriented technology for more than a decade.

A business software component is a self-contained and self-deployable (could be third-party composable) software element providing a set of inter-related services described in well-defined and published interfaces. As the natural successor of objects, components are being utilized in small and large scale software developments. Developing software from components promises benefits such as reuse, complexity management, change management, and time-to-market. The idea of approaching software development using components to imitate its hardware counterpart has been around for a while. But what makes the use of components for software development more feasible at this time is the use of objects and design patterns for component development.

Component Based Software Development (CBSD) focuses on development and composition of components through their interfaces. Composition or integration of components to form a functioning system requires designing collaborative behavior of multiple components to form a system based on a specific component model and component model framework. The current component based development is different from previous approaches, even with object-oriented technology, in its separation of component specification from implementation.

I would like to further write some notes on using components. The above paragraphs can be assumed as simple definition/explanation of components and the need to use them.

On Taking Charge

It was a one summer day in 1990 and I was taking driving lesson to take a test for driving in town. The Learner VW has two breaks, one on the driver side and the other on the passenger side where the instructor sits. On most previous occasions driving around in town, whenever I need to break the instructor already applied the break and my attempt to break would be in vain. I did not like his actions and I made it clear to him as such. Anyways that summer day, we completed our driving around and we were about to park the car. On the parking spot we were about to use, people were sitting - most of them friends of the instructor probably in the same business as the driving lesson teachers. When we approached the parking spot, I started slowing down but not applied the break to a stop. Of course, the instructor applied the break and angrily looked at me. Even though I do not remember how I felt at that time, my response was like - so what you always applied the break with out waiting for me and what is different today?

After a while, thinking back on this incident, I felt awful. I could have run over those people and maimed them or even worse. I asked my self, why did not I apply the break on my own instead of waiting for the teacher? I was in charge - but, not acting as such. On the good side of it, I had taken the lesson to heart. That lesson changed me for good. What I have learned then made me independent - probably too independent.

Now after two decades, I have young kids and assumed a leadership position at work. At work, I am responsible for a team of engineers engaged in software development. The lesson I took to heart in 1990 came to question again. Is it really always good to take charge? Taking charge or being responsible is good and there is no argument here - let's see the flip side of it.

When you are in a leadership position, how do you grow team members you are supposed to lead? Do you think making all the decision by yourself is the right way? When you have kids of your own, how do you allow them to experiment with the world? Do you allow them to figure out things on their own? The 'crime' the driving lesson instructor committed in the above story was to not give me a chance to make decisions on my own. As a leader, you should allow your teams to take charge on their work making most of the decisions. Your task is to help them or facilitating the environment for them to make good decisions. First hand experience in making decisions is the best way to learn.

So, there are times to take charge and know when to back-off from overly being in charge to allow others to grow. This is the leadership challenge - to balance your actions. Encourage your team members to make their own decisions as much as possible - reward them for making an appropriate decision (at least provide a simple Thank You note) or provide a constructive feedback on the decision that did not go well.

Happy Leading!

P.S. Currently, I am reading a book titled

Social Intelligence: The New Science of Human Relationships by Daniel Goleman.

On Board for Learning

Recently, I was on the morning express train going to work and wondering what values I espouse in life. This is not the first time I mused on this thought - it always comes to my mind whenever I read leadership books. Actually, when I was reading the book titled 'The Leadership Challenge', I almost put pen to paper to document my top five values. It did not happen but I still have a plan to do that - one day, that is.

This time the taught was not going away so easily - as it happened many times before. So, after back and forth, much of it negating and commending myself, I arrived to one of my cherished values - it is learning or to be specific continuous learning. Hopefully, I will share my other values in due time.

Now thinking back, it was very apparent - not sure why it took me so long to say it out loud. All along, my subconscious mind knew this but it was in the 'locked door' for my conscious mind. Just to give you one obvious fact - I have been going to school for a long time; I have done under-graduate and graduate studies; recently, I finished my Ph.D. while working full-time and raising a beautiful family. What drove me so hard to go through the gruling process of conducting a Ph. D. research? Now it is clear, right? It is the quest for learning. Learning as in preparing myself for the future!

So, my plan it to continously prepare for the future - continous learning. Hence, starting this blog. I am not sure how often I will blog but I will try it out to enhance the learning process.

Happy Learning!