Analyzing Multi-Tasking Programs Is Different

Posted on September 17th, 2015

“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

Code Refactoring

Posted on September 5th, 2015

“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

Re-familiarizing Yourself with Your Own Programs

Posted on August 11th, 2015

“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

Understanding Other People’s Programs

Posted on June 29th, 2015

“We found that programmers work at all levels of abstraction (code, algorithm, application domain) about equally.”

(A.M. Vans, A.v. Mayrhauser, G. Somlo: Program understanding behavior during corrective maintenance of large-scale software; Int.J. Human-Computer Studies 1999-51)

The combined effect of large scale of today’s software, the wide-spread use of open source components, and frequent project and job changes cause the software engineer to deal with unknown code. While his/her education and experience might help him to build up domain and framework knowledge, he still has to map large sets of source code into models he can work with.

Obviously, any existing documentation and knowledgeable staff will be a great introduction to a large new world. But eventually the engineer needs to work with the source code and find his way around it. Continue reading Understanding Other People’s Programs