Beating the competition to market in today’s global economy means moving faster than ever. Paul Hyman, freelance technology writer and former EIC of Electronic Buyers’ News and Game Power, reports.
February 13, 2006 – Beating the competition to market in today’s global economy means moving faster than ever. Just ask Nokia.
Last year, Nokia got caught without a clamshell-style mobile phone in its product line just when clamshell phones were all the rage. Motorola had a few clamshell designs, Korean manufacturers had many, but Nokia had concentrated instead on providing features such as cameras, music players and removable memory.
Nokia executives quickly realized that without a clamshell phone, the company stood to lose market share. So they jumped into action. Quickly reshuffling priorities and resources, Nokia took phones that were already in development and rushed them to market, weeks ahead of schedule.
Today the company is back on track with folding models that include the Nokia 6101 and Nokia 6102 phones. “In retrospect,” says a Nokia spokesperson, “the situation reinforced the need for a very flexible product-development team able to react to market demands quickly.”
The need for speed is critical in all sectors of device design. So DSO.com asked four industry experts – Joel Osman of Accenture Technology Labs, Dana Gardner of Interarbor Solutions, Jerry Krasner of Embedded Market Forecasters and Djenana Campara of Klocwork Inc.- to share their best strategies for getting new products to market efficiently, effectively and quickly.
Tip #1: Adopt industry standards
Whether you call your goal time-to-completion, time-to-value or time-to-market reduction, standardization looms as the most important aspect of any effort to speed new-product development. By cultivating standards, a company can simplify the number of choices associated with platforms, tools and frameworks, enabling repeatability. “You get the opportunity to partner easily across your own organization as well as outside organizations,” says Dana Gardner, principal analyst at Interarbor Solutions in Gilford, N.H. “This lets you do more collaborative types of development. You can even bring in teams or outside resources.”
Before starting a project, study the available standards and choose those that are right for you, Gardner advises. Rather than starting from scratch by, for example, creating a proprietary wireless-communication protocol for device-to-device communications, a developer would do well to consider such standards as Wi-Fi and Bluetooth. “Companies can also gain advantage by playing active roles in existing communities and standards-oriented organizations,” Gardner says, “because they can, in a sense, steer or direct standardization in ways that may benefit their own initiatives.”
Tip #2: “Plan” rather than “plunge” with simulation modeling
The linear approach to development starts with writing code, knocking off one requirement after another and finishing with a long code base that still needs testing and debugging.
Simulation modeling says, “Don’t plunge. Plan.” Using a modeling tool such as Unified Modeling Language (UML), device developers can organize and design architecture to meet requirements before starting to code, significantly compressing time to completion as well as enhancing the quality of software development projects. Improvements vary widely, depending on execution, notes Interarbor’s Gardner. But in enterprise software development, he adds, it’s not uncommon to see a 30 percent to 40 percent decrease in time to market once UML has been embraced.
In fact, a survey of 1,400 software developers revealed that those who performed simulation modeling and rapid prototyping had both the best design results and the best time to market, says survey author Jerry Krasner of Embedded Market Forecasters in Framingham, Mass. Nearly half of the embedded-software developers reported that they use simulation modeling. “In effect, they test the design, remove errors and make sure they have what they want before they go ahead and actually build it,” Krasner says. “Their approach is just the opposite of writing code, throwing it over the wall, putting it into the hardware and then having to figure out what’s wrong with it.”
Tip #3: Enhance reusability with layering
If you can reuse components and models from earlier projects, you can avoid repeatedly having to start from scratch. And right from the beginning, you are several steps into the production cycle. “Each project need not stand on its own. The more you can use previously written, tested and debugged code, the simpler, the faster and the higher the quality of future projects,” notes Interarbor’s Gardner.
But that approach requires building with a layered architecture and, depending on your corporate culture, it doesn’t always come naturally. “Some people feel it’s easiest to just jump on a PC and code the project from start to finish,” says Joel Osman, senior executive at Accenture Technology Labs. “But they should restrain themselves.”
Instead, Osman says, designers need to realize that each project is an investment in future projects. “Even though you are building a simple device, you have to say, ‘I’m going to buy an operating system and build a technical architecture. I’m going to set up a set of APIs [application program interfaces].'” Developers who do this can develop a library they can later reuse. “It may take a little extra time at first,” Osman adds, “but sometimes you have to take a step backward before taking two forward.”
For example, a phone maker that has built two handsets, both of which run Symbian OS and Java software, should to start thinking about how to reuse pieces of the architecture in the next product line, Osman suggests. “If you’ve never layered before, of course, you can’t just inventory what you have today and look for reuse opportunities,” he says. “But you can start layering with your very next project.”
To do so, developers should ask themselves what they are doing that could be used in a subsequent project. “With your goals in mind, think about what can be reused, pulled out of an application and put into an architecture,” Osman says. “And next time, remember that it’s sitting there for reuse.”
Tip #4: Unravel “hairballs” with static-analysis tools
Previous projects that are not layered present a challenge to development teams. The teams must analyze these projects in a timely manner to determine what’s reusable and what isn’t.
Djenana Campara, founder and CTO of Klocwork Inc., Burlington, Mass., remembers having to pick apart a “hairball of a program” when she worked at Nortel. She determined that it would take four designers seven weeks to extract the reusable artifacts. “There just wasn’t time for that,” she recounts. So Campara’s team turned to a static analysis tool that helped them achieve their goals quickly. It took two designers just three days. “Static analysis tools can zoom into a 10-million-line code product, determine the relationships among the components and perform an impact analysis,” she says. “That way, you’re extracting only the data you absolutely need for your next project.”
Static analysis tools help determine reusability. But they can also uncover a project’s security vulnerabilities and quality defects long before the project is completed. “The beauty of the software is that it lets you analyze the defects and determine how they affect your architecture and design,” Campara says. “The last thing you want to do is fix one problem incorrectly and, as a result, introduce five more.”
Testing and correcting while building-rather than postponing testing and debugging until the project has been completed-is an excellent way to speed time to delivery, Campara adds. “While you are developing, the software works in the background and watches what you’re doing,” she explains. For example, if the developer makes an error, a window might pop up to let him or her know that a buffer overflow has just been introduced. “It’s much easier to make a fix at that point instead of at the end, when you want to get the product out the door,” Campara says.
Tip #5: Adopt life-cycle testing
Another effective way to speed time to market is to use a what’s known as a life-cycle feedback function. In effect, it diagnoses and helps fix systems-even after their release.
One example is Wind River’s Workbench Diagnostics capability. “It can be used to rewind events leading up to a performance problem, help make a diagnosis and begin the repair process for the next set of systems,” says Interarbor’s Gardner. “Or, in some cases, it can be used to actually go in and patch devices currently in use.”
Similar to the way PCs send bug reports to operating system developers, generating patches that are designed to repair software automatically on the fly, network equipment and consumer devices may soon have access to analytics performed in the field, too. “I expect to see information brought back from actual experience in the field,” Gardner says. “That strikes me as a very important element in decreasing time to market.”
To be sure, security concerns could slow adoption, as such access can’t always be given to all devices. But by eliminating product cycles and replacing them with software life-cycle improvements, such access could really redefine time to market. “More information reduces the feedback loop,” Gardner says, “so you can reduce the time to market for improved products in real time.” In that way, he adds, speeding time to market can also bring about real-time improvement.
Klocwork® offers a portfolio of development productivity tools designed to ensure the security, reliability and maintainability of complex code bases. Using proven static analysis technology, Klocwork’s tools identify critical security vulnerabilities and reliability defects, optimize peer code review, and help developers create more maintainable code. Klocwork’s tools are an integral part of the development process for over 1000 customers in the consumer electronics, mobile devices, medical technologies, telecom, military and aerospace sectors.
Klocwork and the Klocwork logo are registered trademarks of Klocwork, Incorporated in the United States and other countries. All other names are trademarks or registered trademarks of their respective companies.