Is your software on fire?

The spectacle of Dell laptops on fire in the summer of 2006 due to Sony battery problems has prodded me to think about product failures. There is nothing so attention-getting as a fire in a conference room. Few people who see this sort of failure will forget what they have seen.

Software failures may not be so spectacular
, but they can be just as memorable to the people who witness them.

Examples from large-scale software systems
: if you were waiting for your baggage in the new Denver airport a few years ago, you may have waited until human intervention delivered your bags, because the bag sorting system failed. And what if you dialed 911 and the call did not go through?

Examples from embedded systems: your cell phone drops a call due to a software glitch in the phone; your hard disk loses track of its position and takes an extra several seconds to recover.

Examples from everyday use of an operating system
: Windows gets confused while processing interrupts from the web browser, and the browser hangs until you reboot; Outlook misses a beat and an email doesn’t appear on the screen when you expect it to.

If the computer or phone were to catch fire when any one of these failures occurs, you can bet that the manufacturer would do a massive recall the way Dell has done. But they didn’t. Instead, they let the users keep on running with a piece of software that “catches fire” regularly. If you’re like most users, you have become accustomed to seeing these fires and dealing with them. But do you like them? Of course not.

What are the consequences?
Word of mouth travels quickly, and these failures have created a large population of users who resent having to use devices and software that fail. Resentment leads users to search for a better alternative. This is good for competitors who offer a better, unfailing solution.

But the whole world of software (and digital devices that depend on software) suffers from a bad image because of these failures. From consumer devices to mission-critical industrial control systems, everyone who has to deal with modern digital devices is gun-shy about failures. And rightfully so.

Is your software on fire?

There are known methods to assure that the software-dependent devices you make will not catch fire. If you’re not certain what these methods are, or who can implement them for you, you need to find someone who can help. But before you call in a consultant, be sure that you’re willing to pay the price: It takes time and money to make software reliable, just as it does in batteries and laptops. Are you ready to buy in?

What is Product Marketing’s role in development?

A colleague asked, “Do you believe Product Marketing could be the bridge between the Engineering and R&D organizations? It seems to me that market requirements are the other piece to incorporate there and Product Marketing could add that to R&D’s specs before working with Engineering to determine what’s feasible and on what time schedule… What do you think?”

It works at the front end
to have an Advanced Development group build prototypes and conceptual specs/models, with specs or requirements added by Product Marketing before giving them to Engineering. But the problems (below) don’t come out until the crunch — when you’re waiting for the next milestone in actual product development.

The problem is that Product Marketing and Engineering
(the department responsible for developing products delivered to customers) have a natural tension: they have to arbitrate between what’s feasible within the time/dollar/featureset constraints; Product Marketing should have the customer deliveries in mind, and should interpret “what the customer wants,” while Engineering is responsible for determining which (and how many) features can be delivered within the cost and time constraints.

As a product is developed, Engineering will naturally come back now and then to renegotiate features vs. schedule (and sometimes $) as they uncover problems (or opportunities) that impact schedule. Product Marketing cannot act as the arbiter for this negotiation — Engineering must participate as a fully-responsible party, determining what can be delivered when. When Product Marketing has all the power in this negotiation, you either get emasculated Engineering, which won’t take any chances because they’re being second-guessed; or you get promises that can’t be kept, because Engineering isn’t really running the development process.

Development Process Stability

After shipping a first product, successful companies face a number of challenging problems in product development, including lack of development process stability as development work scales up. Here are some responses that have worked well in the computer, software, storage and consumer electronics industries.

Why process selection matters now

As Product Development scales up to involve multiple concurrent projects, three things happen to stress the development environment and to threaten its results:
1. The informal processes used at startup no longer work reliably to get quality products produced on time.
2. More managers are needed as the development department becomes too large for one person to manage directly.
3. Supporting customers and manufacturing takes time away from development but offers opportunities for feedback that must not be ignored.

This is an opportunity to choose good processes for the next 5 years. There will never be time to reconsider process selections. The cost of change only goes up.

Managing multiple projects is more complex.
Engineering and Product Marketing must cooperate in new ways to assure that the next generation of products is successful.

Founders and early employees who are technologists have been crucial to success, but they may not be willing or able to make the transition into a development environment that is sustainable for the long run.

Development processes

Development must move out of crisis mode, so that projects can be completed on a predictable schedule.
There may have to be changes clarifying who is responsible for setting project goals.
Project management tools need to be used to manage schedules and feature lists without overloading the development team with overhead tasks.
When a milestone is missed, rapid analysis and decision-making is critical to staying on track for product introductions. Certain metrics are useful here, and project teams need feedback about how they’re doing.

Development tools

Who is responsible for Quality? The Development department must get serious about product quality, even if QA is managed from Operations or elsewhere.
Bring in hardware and software tools for testing, establish disciplined procedures for release, and stay in the issue/correction feedback loop.
In addition, Development can provide useful input to product direction in the next cycle through interaction with customers and field staff.

—–
If you would like more information about how we assist growing companies with managing product development for the long term, please visit https://johnlevyconsulting.com, call 415 663-1818 or email info@johnlevyconsulting.com