Want to know more about software quality? Try these quality resources:
Foundations of Quality
The pillars of achieving quality in your organization.
Why Quality?
See why quality is essential to your success.
Lucid Quality
An innovative method for creating a culture of quality and nurturing software professionals.
Introspection
Lidor Wyssocky's articles on optimizing software development.
Join our mailing list to be always updated.
The Mindset: Lidor
Wyssocky's blog on Optimizing Software Development.
Introspection: Lidor Wyssocky's articles on Optimizing Software Development.
We want our software products to be better. But, we want developers to progress and improve themselves as well. Quality must be reflected in the way developers think, solve problems, design, and write code. These skills require both awareness of internal quality and the extensive knowledge and experience needed to achieve it.
We need a method that helps identify and fix code quality problems as soon as possible, but also teaches developers how to work better and achieve quality to begin with. We need a method that will help us nurture professional software developers.
Having defined code quality, we are ready to set the more detailed goals: the first is achieving short and medium term quality; the second is achieving long-term quality.
The following diagram illustrates how each of these goals translates into concrete concepts, and how they relate to each other.
Our first goal is improving the quality of the software products we create. Traditionally, we apply functional testing, but our definition of code quality helps us broaden the scope of quality to the internals of the product as well.
Short-term quality refers mainly to the functional aspects of the product: causing the product to do what the customer expects it to do, and do it well. As we have already established, the greatest benefit comes from achieving functional quality early on. In other words, preventing potential problems to begin with. Therefore, under short-term quality we should consider the issue of making the code safe and prevent it from being error-prone. We cannot settle for finding existing defects in the code and fixing them.
Unfortunately, many software organizations settle exclusively for short-term quality. Some settle for even less, ignoring the issue of code safety altogether. They are satisfied merely with looking for inconsistencies with the requirements specification. This shortsighted view of quality is the primary cause of ever-increasing development and maintenance costs.
In order to reduce development costs and increase product value, we must ensure medium-term quality as well; we must consider the ability to easily and safely support the product, work with the code, and extend it as needed.
Achieving medium-term quality depends on the first three aspects of code quality. When we write code to be communicative and comprehensible, when we write it to be clear and simple, and when the code reflects a stable and flexible design, we achieve medium-term quality. These attributes of the code make it easy to understand, manipulate and extend. Every maintenance task and each new feature can be implemented easily, safely and promptly.
Short and medium term quality can be broken down into a number of concepts. We want the product to be maintainable, extensible and correct.
Correctness, while intuitively associated with the short-term, can affect the medium-term as well. It is not rare to see incorrect code that seem to successfully implement a given set of scenarios under the current environment despite its inherent flaws. Such code is fragile - the moment a new feature is added, this code will break. The product may be working for now, but it has a potential functional problem waiting to emerge.
Memory corruptions are a great example of such flaws. Code that causes memory corruptions may run in a certain environment without any noticeable effect. However, as soon as a single line of code is changed, added, or deleted, the product crashes. Identifying the source of the problem at that point, when the product is in its maintenance phase, is by far more complex and expensive than preventing it during development.
Maintainability and extensibility belong to the medium-term. Again, this scope does not imply that they are of lower priority. Medium-term quality is important both to the organization and to the customer. Neglecting medium-term quality will result in loss of profit and pose a risk to the reputation of your organization.
Extensibility, maintainability, and correctness all rely on a fourth concept: built-in quality. Trying to address extensibility, maintainability, and correctness as an afterthought (when the product is already in an advanced development phase) will result in enormous overhead and a major increase in development costs. These quality attributes must be built into the product to begin with.
Both short term and medium term quality relate to the product under development. Clearly, this is an important goal, which constitutes the rationale for improving code quality. We would like to perfect the products we create so they will have the attributes listed above. The process we will define will address these concerns and support the immediate improvement of our products. However, we want this process to have an even greater benefit - we want it to create a change for the long run. This is where the second goal comes into the picture.
The quality of the concrete software product is obviously an important goal. Still, if we aim to achieve built-in quality, which means preventing code quality problems instead of merely finding and fixing them, the best thing would be to teach our software developers how to write good code to begin with. Finding a problem in the code before it is delivered to QC is by far less expensive than finding the same problem during formal testing or after the product has been deployed. But, it still has a cost. Avoiding a problem altogether is undoubtedly the most cost-effective approach.
If we could somehow use today's activities to improve the quality of code that will be written in the future, the benefit from these activities would be immense. The best way to achieve that is by investing in the developers themselves - providing a way for them to constantly improve their skills. We need to give our developers a way to implement built-in quality so they can write quality code effortlessly.
Long-term quality consists of two primary concepts. The first is awareness and ownership of quality. Developers must accept their responsibility for the quality of the code they write, and for the quality of the product as a whole.
Quality is the responsibility of every participant in the development process. The developers are, of course, no different. Still, many developers are not aware of the relation between the design they create and the way it is implemented and the quality of the product.
Most developers are aware of the importance of the functional aspects of their code. However, many developers still have to be taught the importance of the code's internal quality in the context of reducing development costs and creating a product that lasts longer.
Accepting responsibility for quality is an important step toward working better and creating better products.
Awareness of the importance of code quality is essential, but it is not sufficient. In order to create quality products, developers must gain the knowledge and the experience needed in order to create good designs and write good code. It is the responsibility of the organization to provide them the means to gain this knowledge and to build up their experience. The benefit to the organization will significantly exceed the investment in these means.
Building knowledge and experience cannot be done overnight. It is an ongoing effort, which has to be backed up with vision, commitment, and a plan.
Awareness of quality and the knowledge required to achieve it are based on a third concept: quality-oriented mindset. Quality-oriented mindset drives developers to be responsible to the quality of the product they create and to strive to becoming professionals.
Do not be misled by the phrase 'long-term quality': you cannot afford to postpone addressing this goal. The longer you wait, the harder it will be to guide your developers to the right direction. They will get used to performing their tasks without any consideration of quality; they will adopt bad design and coding practices. The longer you wait, the harder it will be to get rid of these bad habits.
Promoting long-term quality is in the best interests of both the developers and the organization they work for. The benefit to the organization is obvious: the organization's most important assets (its developers) will become more professional and better skilled. Future products will be higher quality by definition: the people who create these products will be doing their work better. The benefit to the individual developer is the same: improving her skills and becoming a professional software developer.
The goal of achieving long-term quality must be inherent to the solution we define for achieving code quality. It cannot be achieved as an afterthought. Many approaches deal only with identifying problems in concrete products without addressing the impact long-term quality has on the costs of development.
As you will see, the approach we will use throughout the rest of this book defines an inclusive framework with a clear vision of how long-term quality can be achieved using the same resources used for perfecting the quality of the concrete software products under development.
Improving the software products your organization creates and improving the skills of the developers who create them are important goals to your business. These goals will help you reduce development costs, create products with higher value, and make your customers more satisfied.
Still, if we want our solution to be effective and useful to a business organization it must be lightweight from the development team's perspective.
A process that requires extensive investment of the developers' time will not be accepted well by them. It will also not be effective from the organization's perspective.
The activities for achieving code quality must be integrated naturally in the development process and reduce the overhead to the development team to a minimum.
Formally defining goals is a crucial step in the process of achieving code quality. Some organizations tend to adopt a certain process or approach without defining their goals first. This strategy is bound to fail. Without clear goals, the people involved in the new process will soon lose their way.
The goals we define are like a lighthouse showing the people involved in the process their way. Whenever there is a dilemma regarding a certain aspect of a new activity, this lighthouse will guide them towards the right path.
If your organization will not explicitly set these goals and publish them, it will send an ambivalent message to developers, team leaders and managers. People will wonder what the purpose of these new activities is. They might get frustrated they are being forced into a new process, which seem senseless with no clear goals defined. Most of these doubts will be avoided if Management will take the time to explain the rationale of the new system and its benefit to the people this system is designed to affect.
The Quality Within describes an innovative approach to systematically promoting the internal quality of software products. It offers a unique method which puts the developers at the center of this effort, such that you improve the professional skills of your developers while perfecting your software products at the same time and using the same investment.
Want more information on The Quality Within? Contact us.