Managing embedded software

Greg Bergsma of QNX Software believes that if you put the right architectural framework in place, your large team embedded software projects would run much more smoothly.

Many embedded projects start small. But then, demands for more features and more product versions start pouring in. Pretty soon,

a project employing just a handful of developers has transformed into a large team effort. With that growth comes a challenge: how do you integrate code from many new developers, or multiple teams of developers, and still maintain reliability in your products? And if problems do occur, how do you identify them (quickly) if you are using code from 20, 50 or even 100 programmers.

There are software methodologies that address such problems in a generic, non-embedded environment, but few exist for embedded developers. Still many of these problems can be solved easily by taking advantage of an underutilised – often entirely ignored – component of virtually all modern CPUs: the MMU(memory management unit).

To handle demands for new product revisions and features, it makes sense to leverage code from previous implementations of your product. But the danger here is that mistakes of the past will be amplified with each new, and increasingly complex, generation of product. These mistakes can directly affect the productivity of development staff and make the configurations of various teams of developers more difficult to manage.

Let’s identify some common problems facing large development teams. First there is version control, especially if you have multiple product versions involving multiple code versions, multiple source control trees and multiple teams. Then there is integration and quality assurance testing – which also consumes a significant proportion of development time. And because of the enormity of the source code, no single programmer can understand the entire code base – a problem made worse every time a programmer experienced with the project leaves for another company.

Anyone in charge of large teams of developers probably recognises at least a few of these problems. Still many would be surprised to learn that basic decisions on systems architecture can ease all these problems.