PRODUCT DEVELOPMENT INSIGHT

The following example examines a project to develop software for an embedded medical device.

A product was to be developed on a custom hardware platform. The medical device company had a team of software developers (Team A), but not enough resources to produce the product in the scheduled time. The company sought outside resources and found them in a contract medical device developer. The contract developer assigned another team of developers (Team B), which was similar in size and qualifications to Team A.

After several meetings, the two teams agreed that the best approach was to divide the software into two relatively independent pieces, the application code and the platform code. Team A was assigned the application code because it presumably had a better understanding of user needs and was closer to company resources to develop the application interface with marketing and clinical specialists. Team B was assigned the platform layer that became a custom embedded operating system replacement that interacted with the hardware, which was still in development. In the end, it worked out that the two groups each had roughly 20,000 lines of code to write.

Team B spent roughly 4 weeks discovering, negotiating, documenting, and reviewing requirements. There were requirements for interacting with the custom hardware and requirements for interacting with the application layer of software being developed by the other team. Once the requirements had been nailed down, Team B spent 2 1/2 months detailing the software design down to the function level and 4 additional months implementing it. Independent testing took about 3 weeks. The entire project took just over 7 months to document, implement, and test.

Team A did not follow a controlled design process and skipped both the requirements and design documentation, thereby saving 3 1/2 months at the start. The software engineers (programmers) started writing software immediately. Without clear requirements or design guidance, Team A iterated for 11 1/2 months to write the code. Testing took more than 3 months to complete. Team A even had the benefit of the requirements Team B wrote for interfacing to the platform layer. Furthermore, as it became more apparent that Team A was slipping off schedule, more of the software functionality was shifted to the platform for Team B to implement.

Team B, which was also hampered by debugging the software on new custom hardware, finished the platform software and handed it over to Team A with a complete set of documentation, test protocols, and test results. Team A worked more than 7 months longer to finish its software—almost twice as long as Team B.

Team B produced very solid software. Only three defects were found in Team B’s platform software during the integration process over the next 7 months. Team A’s software was troubled with hundreds of defects that surfaced over their 3-month test period.

What was the reason for the dramatic disparity? The two teams had similar years of experience and were similarly talented. Implementation for Team B took place in a relatively straightforward process. Pages from the design document were simply converted into code. Team B was able to add one more engineer to the project during implementation. This was easily accomplished because the implementation required little knowledge of the overall requirements or design to translate each individual function’s design into code.

To be fair, Team A was pressured by company management to begin showing progress by writing code very early in the life cycle. Spending time on documentation was seen as extraneous overhead that would only add to the schedule. Team B had the advantage of not being local and not being subject to the daily oversight and pressures of the schedule-conscious management.

Team A iterated many times: writing software, showing it around to get opinions, then rewriting code to respond to the criticisms.

Many of Team A’s defects had to do with lack of coordination among the team’s developers. Time could have been saved by communicating the intended operation of the software through specifications rather than through prototype throwaway code.

As schedule pressure mounted, Team A was unable to bring on additional resources to help. However, bringing in new resources that late in the project would actually have slowed the team down. Interactions with the new resources would have had to be through verbal communications from memory or from reverse-engineering existing software.

In the end, the stark difference in Team A’s and Team B’s performance and results didn’t result from a disparity of talent or dedication. It came down to planning, communication, and using a well-defined development process—exactly what the design control requirements of the QSR suggest.