Wednesday, July 25, 2012

The 14 Rules of Management for a Successful Software Product Company (Rule #8)

A quick overview of the Test-driven developmen...
A quick overview of the Test-driven development lifecycle. (Photo credit: Wikipedia)

Following rule #8 of the management rules of Kelly Johnson can save a product company lot of money.
Kelly Johnson is famous for building the impossible. The 14 rules of Kelly Johnson used to manage his famed "Skunk Works" are well documented in their original form.  These ideas are applied to software products for product companies. "Be quick, be quiet, and be on time." and  “Release early, Release Often, but with quality”

Kelly's rule:
8.
The inspection system as currently used by the Skunk Works, which has been approved by both the Air Force and Navy, meets the intent of existing military requirements and should be used on new project. Push more basic inspection responsibility back to subcontractors and vendors. Don't duplicate so much inspection.

Different software development models will focus the test effort at different points in the development process. Newer development models, such as Agile, often employ test driven development and place an increased portion of the testing in the hands of the developer, before it reaches a formal team of testers. In a more traditional model, most of the test execution occurs after the requirements have been defined and the coding process has been completed. As a result most product development has layer upon layer of testing. There is Unit testing, Integration testing, System testing, System Integration testing. Installation testing, Compatibility testing, Regression testing, Acceptance testing, Alpha testing, Beta Testing, Functional and non-functional testing. Destructive Testing, Performance testing, Usability testing, Accessibility testing, Security testing, Internationalization and localization testing and that is just getting started.

Many of these tests are performing the same test over and over again.

But wait a minute! We use Hudson (or XYX automated continuous build and test products).  Maybe so, but it still took time to develop that test. And that test is only good if someone looks at the result. (I have seen many automated processes that every night the nightly build had failed the same unit test and no one paid any attention to it.) 

Automation only saves the expense of repeating a test. It can increase the cost of developing the test, and you had to pay to get that automation. 

So, why test if it adds to the cost of the product.  You test because you need to prove that your product meets the needs of your customers. You test because you need to test to prove that it meets the requirements stated in a contract/or meets your specification.  You test to prove to that your product is safe. You test to prove that your product is a quality product. And most importantly you test to reduce deferred cost.

So what is deferred cost. Deferred cost is the liability payments if your product is not safe. Differed cost is the loss in revenue due to decreased sales if your product is not safe. 

If the above is starting to sound like Taguchi method or Six Sigma testing methodologies it should.  Testing should be thought of as a cost optimization problem. How can you lower/optimize the cost of testing to maximize net short profit and minimize the deferred cost thus improving long-term profits.


Product rule:
8. Testing and inspection is expensive, but not testing or inspecting can be more expensive. Optimize your testing to only that necessary to prove you: 1) meet the needs of your customer; 2) meet all stated contract requirements; 3) have a safe product 4) have a quality, high value product. Don’t duplicate or perform any other testing.


Enhanced by Zemanta

No comments:

Post a Comment