Embedded software projects are simply becoming bigger and more complex. Lines of code (LOC) in telecommunications applications, one measure of complexity, are growing at a 26% clip annually according to estimates from Venture Development Corp. Not enough developers exist to bring these projects to market within time and budget constraints. Each year, the number of new embedded software developers appears to be growing by less than 10%. Other anecdotal indications reveal that developers are required to do more, and at a quicker pace, with little increase in human resources at leading OEMs.
Some attempts to overcome the complexity/LOC gap include more advanced tools, modeling frameworks like UML, and of course, human capital. Sometimes, this includes adding developers internally. But more and more, the answer is to outsource portions—or in some cases, the entire project.
Yet a new tactic has emerged. Some of its basic concepts, like iterative development, may date from the 1950s. The idea is to change the development methodology. Some of the more common methods include pair programming, iterative or spiral development, and Extreme programming (XP). XP combines the pair programming and iterative or spiral development with other concepts to have all the best ideas in one methodology.
The waterfall methodology is the typical methodology for embedded projects. A requirements document is generated with customer input. The components are parceled out to several developers that code in isolation. Ultimately, the parts are integrated and shipped. Resulting software is often late and less than what was desired. VDC estimates that 57% of embedded projects are cancelled or delivered late.
How do these methodologies bridge the gap?
XP emerged in the 1980s, and it has gained some traction in the development of large enterprise applications. It's rarely used in embedded applications where traditional project and team size have been small and relatively easy to manage. But as embedded projects increase in size, XP and its component methodologies like iterative/spiral development are generating interest from OEMs. Perhaps the best known endorsement for these methods is the U.S. Army mandate for Spiral Development on the Future Combat System.
Should you change your methodology? If your team can't deliver on time and in spec, something must be done. Nonetheless, these concepts are definitely a change in culture and work style, and not for every organization. Many Internet and hard-copy resources are available for designers interested in exploring these methodologies and implementing them in part or as a whole. That said, projects are only going to become more complex, requiring new technologies and methodologies to bridge the gap.