| To DSO, or not to DSO -- a developer's perspective |
by Christopher Stone (Mar. 29, 2006)
Foreword: Yesterday, we published an article defining Device Software Optimization (DSO), based on an interview with John Bruggeman, chief marketing officer at Wind River, which coined the term. In response to that article, we received the following thoughtful "rebuttal" from Christopher Stone, offering a developer's perspective on DSO. We invite our readers to voice their own opinions on the topic, using the talkback thread at the bottom of the page. Enjoy . . . !
To DSO, or not to DSO -- a developer's perspective
by Christopher Stone
Wind River has a message for us. Embedded software development needs a new process, they say, and "Device Software Optimization" (DSO) is the answer. Is it, though? Does DSO deliver true value to the developer, or does it just sell well in the board room? When you visit the DSO website, you will find a significant amount of content from the CEO's, vice presidents, and engineering managers of some of the world's largest embedded software product companies. There is an obvious buy-in from the management side of the embedded software development business.
The process of embedded software development does need to change for the following reasons: - Social -- in order to compete with offshore development costs and retain jobs in North America and Europe, we have to make developers more productive.
- Complexity -- the increasing throughput of hardware means that embedded devices can fulfill more functions. This translates directly into more complex software. Since the complexity vs. development cost curve is not linear, better processes save large amounts of development cost.
- Robustness -- consumers measure products primarily on reliability.
- Security -- insecure is unreliable.
This article examines the DSO message from the engineer's point of view. In this article, I attempt to separate the engineering value from the marketing chaff in the Wind River DSO message.
According to John Bruggeman, Wind River's chief marketing officer, DSO has three main aspects: - Developers should build their devices with application-enabling platforms instead of doing it all themselves.
- Application-enabling platforms should be based on open standards.
- Application-enabling platforms should be globally supported by a multi-vendor ecosystem of commercial suppliers.
I am going to examine two of these points, numbers one and three, because point two is pretty straight forward.
Software reuse
Point one is all about software reuse -- that is the engineering value. However, embedded software reuse is no different than software reuse in the desktop application industry. The state of the art in software reuse today requires the blending and successful execution of the disciplines of architecture, design, and programming based on fine grained software components. What does that mean? Application-enabling platforms are too big -- components are what the industry really needs. Positioning application-enabling platforms as the answer the industry needs is the marketing chaff.
The problem with platforms is that they limit choices. Developing devices that sell requires a healthy dose of innovation. Innovation comes from diversity; from choices. One of the primary catalysts for the rise of open source software is the diversity of choices that it presents, and the innovation that it fosters. Choice creates innovation, platforms stifle it. I know from experience that developers today do not use application-enabling platforms unchanged. The vast majority still delve deep into the middle of them to enable the choices they are looking for -- the choices they hope their competitors haven't thought of. Those changes invalidate the value of a tested platform. Tested components would deliver more value.
What does the embedded industry need to enable software reuse? We need tools, we need training, we need mentors: - We need modeling tools that allow us to combine components into designs and automatically generate code
- We need test tools that allow us to build up databases of test cases during design and automate testing
- We need simulation tools that allow us to quickly try out new ideas and develop applications before there is hardware
- We need online courses that allow us to upgrade our skills at a reasonable cost
- We need mentors that can guide us
- We need it all to support the entire body of open source software in the world, and not just a productized subset
Multi-vendor globally supported solutions
It is a fact that the hardest tradeoff in a design is the cost of re-engineering components to work together vs the cost of developing from scratch. Thus, multi-vendor solutions designed to work together is the engineering value behind the third aspect of DSO.
To find the marketing chaff, consider that almost every embedded project gets into some kind of trouble with on-time delivery. Even projects that are completed on-time probably had engineers working late into the night in order to meet the schedule. The concept that there is a global company waiting to take your call and parachute a local expert in to your project to save the day is powerful, but unfortunately, is the marketing chaff behind the third aspect of DSO.
The vast majority of problems found at the last minute are solved by the engineers developing the device -- either through working around a bug or solving the bug. It is true that an engineering manager will report problems to the software supplier, but, she doesn't sit and wait for the supplier to solve the problem. The engineers on the project will look for a way to get around the problem. Instead of focusing on global support delivered locally, it is more important to provide the customer with solutions that include the source code. The source code does not have to be under a free license, but, it must be available to the engineer at 3am when his test case fails.
Conclusion
DSO has some obvious value behind it. The DSO message would not be picked up by others if it was only marketing spin. Nonetheless, in order for DSO to be more than a passing fad, it must deliver value to the engineer at the keyboard, without vendor bias. The current DSO message needs to be changed because it is being used as a vehicle to influence decision makers toward solutions that are not optimal. The values of software reuse, open standards, and vendor diversity are honorable, but, they are values that have been honed by the desktop application market over the last ten years. They are not new values, so giving them a new name is questionable. Embedded developers just need to be given the tools, training, mentors, and source code to realize these values in the embedded software industry.
 About the author: Christopher Stone is a partner in Sombrio Systems Inc., a consulting firm that specializes in real time, embedded, open source software. He is the founder of the Industrial Grade Linux distribution Mekanix which aims to enable Linux in factory automation and plant intelligence applications. He holds a B.Sc. in Computer Science from the University of Victoria in British Columbia, Canada, and has worked as an embedded software developer for 22 years.
Do you have comments on this article?
talkback here
Related stories:
(Click here for further information)
|
|
|
7 Advantages of D2D Backup
For decades, tape has been the backup medium of choice. But, now, disk-to-disk (D2D) backup is gaining in favor. Learn why you should make the move in this whitepaper.
4 Legal Reasons to Control Internet Access
The Internet is obviously a valuable resource for many organizations. However, many are exposed to legal liability concerns because they fail to control Internet access. Learn if you're safe in this white paper.
Rapidly Resolve J2EE Application Problems
Whether you are in the process of building J2EE applications or have J2EE applications already running in production, you must ensure that they deliver the expected ROI. Learn how in this white paper.
Load Testing 2.0 for Web 2.0
There are many unknowns in stress testing Web 2.0 applications. Find out how to test the performance of Web 2.0 in this white paper.
Build Better Games Online
For the game infrastructure providers, life is complex. Making money from games has become more complicated. Why? Find out in this white paper.
Building a Virtual Infrastructure from Servers to Storage
This white paper discusses the virtual storage solutions that reduce cost, increase storage utilization, and address the challenges of backing up and restoring Server environments.
Gaining Faster Wireless Connections with WiMAX
Welcome to what is quickly becoming the hyperconnected world where anything that would benefit from being connected to the network will be connected. Learn more in this white paper.
Is Your Desktop a Security Threat?
The new wave of sophisticated crimeware not only targets specific companies, but also targets desktops and laptops as backdoor entryways into those business’ operations and resources. Learn how to stay safe in this white paper.
Increasing SAN Reliability by 100 Percent
Storage area networks (SAN) are a strong part of storage plans. Learn how to increase your reliability and uptime by 100 percent in this case study.
|
|
|
|
|
news feed