Earthquake Proof Your Software Development

In this blog we tend to focus on the benefits and opportunities that arise when using virtual prototyping. However, in real life we well know that any situation bears not only opportunities but also risks. I was reminded of this by the recent earthquake disaster in Kumamoto Japan. Having lived in the most earthquake prone areas in the world for the past 10 years, I know firsthand how easy it is to ignore the risks. In Japan the preparation strategy is a combination of a stoic acceptance and continuous preparation and training. When bringing this mindset into the business world we typically refer to it as risk management, a well understood discipline but often neglected especially in the realms of ever tightening market windows.

In March 2011, I had a personal experience in this intersection of disaster and business. At that time, I consulted a Japanese customer on the implementation of a typical benefit driven virtual prototyping project. The project goals were textbook: pre-silicon software development, improvement of inter-team communication and dependency reduction on physical hardware.

As with any such prototyping project the development plan mapped the activities of the software project plan onto the different development targets, in this case virtual prototypes and engineering chip samples. The project was running fine and the benefits were well established. In the upcoming project phase, the software engineers were supposed to use the first set of engineering samples for their work. These samples were scheduled and supposed to arrive in a couple of weeks. Just at that time, on March 11^th, the big tohoku tsunami and earthquake hit Japan with a magnitude of 9.0, causing unthinkable personal tragedies and damages. As a small footnote in the overall development of events, the earthquake also damaged the fabs that were supposed to deliver just those engineering samples we were waiting for. With all the rippling effects and ongoing triage the availability of hardware was moved out further and further and their availability became pretty uncertain at that point.

At that time, which you can imagine was a very surreal setting in Tokyo, we sat together with the software engineering managers and revisited the software development plan. We found that the initial plan just assumed hardware availability but it was not required. We analyzed that most software development tasks could actually be done on the existing virtual prototype “as-is” and only a few tasks required little enhancements. Within a couple of days those enhancements were done and the customers virtual prototyping team packaged and shipped the new version of “virtual hardware” to the software engineers. When finally, after several months’ delay, the engineering samples arrived the software teams insisted on using the virtual prototype for its debugging advantages and its stability. The project become a big success and virtual prototyping methodologies became well established for all the following projects.

Late hardware is an all too common reason for delay and failure in today’s embedded software projects. The reasons for late hardware vary and the above example is certainly an extreme example. The lesson learned however is that virtual prototypes hedge the risk of late hardware. In one of my future posts I will explain how to also ensure that the virtual prototypes are on-time. Until then, stay safe.