Device software optimization is all about elevating choice from the individual domain beyond the project team and all the way to the enterprise level. Yet too many enterprises have not yet accepted this challenge.
True, many development teams already use the same tools. For example, since the end of the 1980s, C has become the dominant programming language for device software development. As a result, developers—an evolved species that can be traced back to the “programmers” of the early days—can now move from project to project without climbing a steep learning curve, the way they must when an unfamiliar programming language is used on a new project.
Imagine how bad it was in earlier days, when most programming was done in assembly language. Today, by contrast, a developer cannot only hit the ground running on a new project, but he or she also can adopt a new architecture quite easily.
Because the C language, thanks to its many compilers, supports virtually all architectures, C now is used in virtually all projects, with only rare exceptions. All developers, in turn, know how to program in C, which makes them available for new projects with only minimal retraining.
Clearly, the benefits of using C dwarf the benefits of having a choice of programming language for each project. Yet the same cannot be said for other programming tools, such as editors, project builders, code browsers, and debuggers. These tools, unlike high-level language compilers, do not have a standard to follow.
No single tool has emerged to dominate these processes the way C has among languages. Instead, today there are dozens, probably even hundreds, of tools used throughout the development process. Just looking at debuggers, a recent Venture Development Corp. survey found more than 30 debuggers being used by device-software developers. Clearly, some are more popular than others, but none is dominant.
The reason, I believe, is obvious: Each developer or development team chooses a debugger based on the tool's familiarity, features, ease of use, cost, and compatibility with previous designs. Each team, by making this choice, essentially values the benefits of choice over those of standardization.
But wait, did I say “development team?” Isn't it true that development teams tend to use the same debugger throughout the team? What about the editor? Browser? Builder? Yes, a development team tends to use the same tools. Seems beneficial, doesn't it? By collectively deciding to standardize on a particular tool set, a team enjoys the benefits of both choice and standardization.
Now if these benefits apply across the members of a team, why can't similar benefits be enjoyed across multiple teams throughout an enterprise?
They can. If an enterprise is willing to make an enterprise choice, then the same benefits already enjoyed by development teams will become available to the entire organization.
This is what DSO is all about: elevating choice from an individual domain, moving it beyond the project team, and bringing it all the way to the enterprise level. In this way, the enterprise gets the benefits of developer interchange, no learning curve for new tools, easier software re-use, and shared projects. That's an optimization—device software optimization—of the entire process across the enterprise, rather than just for an individual or single project team.
Of course, there is a limit to standardization. There's a line of demarcation between the things you can standardize and the things you can't. It falls somewhere between the development tools and the operating system, with middleware on either one side or the other (see illustration). Above the line, there's an opportunity for the benefits of DSO through an enterprise-wide, standardized choice.
Below the line, each project and each device has its own individual needs that demand custom application software and an operating system suited to the needs of that device, whether it be memory footprint, real-time responsiveness, or licensing terms. What's critical is the ability to choose an OS that's both appropriate for a given project and that can be used with enterprise-standardized tools.
Until we can choose the best OS technology for each device and still use an enterprise-wide tools solution, we're not really optimizing device software development. We're not employing DSO.
It is possible to have an optimized tools solution across the enterprise, and also have OS choice at the project or device level. In fact, in each area, choices abound. But to truly achieve the promise of DSO, an enterprise must take the following three steps:
1) Choose a development tools solution that supports all projects to be undertaken by the enterprise;
2) Choose the best OS technology for each particular device under development;
3) Make sure the technologies selected in steps 1 and 2 can be used together without requiring additional integration work.
Following these three steps yields nice benefits. Developers can shift from project to project without re-training. Optimized software runs on each device. And developers no longer need to worry whether operating system A can work seamlessly with tool set B.
DSO can be implemented as a balance between standardization and choice, two good things no enterprise should give up. Enterprises should standardize as much as possible. And where they cannot standardize, enterprises should choose individual device-software solutions that are compatible with the portion of software they have standardized on.
Only with this kind of enterprise-level thinking can we achieve the full promise of DSO.
John Carbone is vice president of marketing at Express Logic Inc., a provider of real-time operating system solutions for deeply embedded applications.