Increasing your software teams efficiency and code quality

2/23/2009 12:00 AM EST

As we move to the next generation technologies, software production is becoming a much larger part of the embedded product development process. Critical areas like brake systems of automobile industry, gas control systems and in-home appliances use software technology with quality becoming a key factor.

Things like time to market, defective processes and resource constraints leads to such defective unstable systems. But end users and customers prefer products with stability and quality rather than feature-rich, but unstable, systems.

When we say defective product, it's not the product but the method used in creating the product that is defective. Sometimes lesser energy within the system could also lead to such unstable systems. Now let us look into seven basic areas of a software development process that need increased attention to improve quality of the system.

#1 - Document close to the source
Software developers presume documentation is not part of their pie. As a result, the assumptions made during coding do not get captured properly. Knowledge does not transfer properly and this often leads to catastrophic effects.

For example, while programming, a developer accesses a structure member by indexing or assumes that the byte in the nth offset is of interest to him. In the process of the maintenance lifecycle when a new engineer adds a member to the structure or reorganizes the structure, the code will become messy.

If no proper explanation is attached to the piece of code that assumes indexing, data recovery from the defect will be tricky. Such assumptions might not also get properly captured in the design.

It's better to document closely to the assumption made in the code. Tools such as doxygen help us generate design documents from the source code. Documenting close to the source will reduce the risk of assumptions and also reduces the time required to create separate design documents.

Asserts are also a kind of documentation that should be added to validate the assumptions. Lesser assumptions during development lead to more stable quality systems.

#2 - Version-control system
One of the important stages in any project life cycle is version control. Normally a version-control system is viewed as a place to store project documents. A version-control system is a company's knowledge base.

Version control can be a valuable source of knowledge for future engineers or when we dig back into a project after a few years. Let's consider a scenario involving a of change in the source file. Engineers generally update the version-control systems as below:

------------------snip------------------
From:
-----snip-----
free(ptr);
-----snip-----
To:
-----snip-----
if(ptr != NULL){
    free(ptr);}
-----snip-----
Log Message:
Check pointer before freeing.
------------------snip------------------

As we look into the change log after years or a new engineer looks into the change log, there would be no clue why the code was changed. The process has to be adapted to ensure that the change log conveys the change reason properly.

In a summary, the log has to convey the what, why, and how of the change made. "What" could refer to the bug ID, "why" could refer to the root cause, and "how" refers to how the problem was solved. Such efforts minimize the assumptions made after years when the same piece of code requires some refactoring. Minimizing assumptions helps to increase quality of the systems.