We confidently release without a dedicated testing phase.
Let’s cook up a bug pie. First, start with a nice, challenging language. How about C? We’ll season it with a dash of assembly.
Next, add extra bugs by mixing in concurrent programming. Our old friends Safety and Liveness are happy to fight each other over who provides the most bugs. They supplied the Java multithreading library with bugs for years!
Now we need a really difficult problem domain. How about real-time embedded systems?
To top off this disaster recipe, we need the right kind of programmers. Let’s see... experts... no... senior developers... no... aha! Novices! Just what we need.
Take your ingredients—C, real-time embedded systems, multitasking, and don’t forget the novices—add a little assembly for seasoning, shake well, and bake for three years. (I do love me a bug pie.)
Here’s how it turns out:
The GMS team delivered this product after three years of development [60,638 lines of code], having encountered a total of 51 defects during that time. The open bug list never had more than two items at a time. Productivity was measured at almost three times the level for comparable embedded software teams. The first field test units were delivered after approximately six months into development. After that point, the software team supported the other engineering disciplines while continuing to do software enhancements.
These folks had everything stacked against them—except their coach and her approach ...