“When debugging, novices insert corrective code; experts remove defective code.”

Richard Pattis, Quotations for Learning and Programming

Advances in static analysis tools have made their use an increasingly standard and indispensible step in software QA processes. Large gains in testing efficiency and program quality result from their capability to identify a broad range of problems in software programs. However, users are still left with the challenge of eliminating the defects that these tools find. Through SARIF (Static Analysis Results Interchange Format), static analysis environments can be extended with additional tools targeting various aspects of this downstream work. Static analysis results can be imported into program understanding tools in order to examine problematic code and determine the severity of its defects. Program quality review tools can methodically guide, track and document the results of these examinations. Bug tracking tools are able to record the history of specific defects. By extending the tool environment, the benefits of static analysis tools can be carried further into your development process. Continue reading Using SARIF to Enhance Your Static Analysis Toolset

“Multitasking has entered the mainstream of embedded systems design”

Andrew Davis, Embedded Systems and Multitasking Software, 1998

Using multi-tasking in embedded systems is a must today, given the advantages of separating overall control and each task activity. Affordable, powerful hardware and off-the-shelf real-time operating systems are the enabling factors that made this the norm today.

While a newly designed multi-tasking application has a clean and comprehensive design, that design will degrade with changes over time. If fixing an issue is assigned to a new programmer, or even someone previously familiar with the application, understanding the as-built behavior can become a challenge. Quite a number of the steps in (re)learning the software are the same as for sequential programs. But a number of key analyses are specific to multi-tasking applications. Continue reading Analyzing Multi-Tasking Programs Is Different

“Refactoring is a disciplined technique for restructuring an existing body of code, altering its internal structure without changing its external behavior.”

Martin Fowler, www.refactoring.com

Code has a tendency to stray from clean design as it evolves through enhancements and fixes. This degradation increases maintenance cost and decreases performance and stability. In the past, the solution for degraded code has been “the next big revision”, aimed at a redesign and rewrite of the system. Quite often, such projects have ended up being too ambitious, missing their deadlines and budgets, and resulting in systems with reduced functionality.

Refactoring approaches the need for improving the code by spreading out a series of small changes over time. Each change preserves the system functionality, and can be verified immediately without having to wait for a major release and QA effort.

How do we find candidates for refactoring? Continue reading Code Refactoring

“In practice, most programmers forget many of the details of their own programs a few months after they have finished working on them.”

(G. Branson, D. Rosenthal: Introduction to Programming with Visual Basic .NET, 2005 Jones and Bartlett Publishers)

This is the typical motivation for documenting code through design documents and comments in code. But the issue with those is that after a few change cycles, the documentation just does not cover everything anymore. That’s where tools answering questions about the as-build dependencies in your code become important.

Who hasn’t seen this scenario? Initially, a module (or class or otherwise encapsulated part of the code) has a clean structure, well-defined interface, and is easy to understand. Some time later, there is a need for an enhancement; with some tweaks, this module now fits these requirements as well. What a great design! While the tweaks required a few compromises and the data and interfaces are spread out a little more, but we are certain to remember those few gotchas next time we need to make changes. And then in middle of some unrelated project, an emergency comes up with this code and quick action is required. Fortunately, we know everything about this code and are the best resource to fix these performance concerns. Surprise, things in the previous enhancements start to break. Continue reading Re-familiarizing Yourself with Your Own Programs