ANSWER

Have you heard the phrase...?

"If your project is leaking, check the bathtub."

In engineering and product development fields where the reliability of a product is critical, the bathtub curve is more than a topic of conversation to be had with your interior designer or at your local home improvement store.

The bathtub curve is a graphical model or visual representation of the failure rate of a product over time. In general, one would expect the failure rate to vary over the lifetime of a product, as follows:

• early in life of the product - higher-failure rates which are decreasing over time, as issues are fixed and addressed - known as early failures

• core life of the product - a more level/constant/predictable failure rate known as random failures

• late stage of the product's life - increasing rate of failures, generally different types of failures than in the early stage - known as wear-out failures

If a product's observed or reported failures are plotted on a graph, over time, the result looks like bathtub hence the name: bathtub curve.

Image Source: Wikimedia Commons

The early failures, also known as "infant mortality failures" are expected to exist but are also expected to rapidly decrease as product issues are quickly addressed and remediated.

Wear-out failures are also expected to occur but only towards the end of the projected life of a given product.

How does the Bathtub Curve apply to software projects?  How can it be useful?

The bathtub curve can be a useful tool to plot and visualize the expected quality of the software product, system, or sub-module but tracking the failure rates over time and assessing whether the observed failure rates are in line with the expected failure rate. 

• If the actual failure rates are higher than anticipated, it can signal a flawed development process or a subpar requirements definition practice.

• A rapidly decreasing failure rate in the early stage may be the result of a mature and agile development shop where the product is thoroughly tested and immediately rectified as soon as failures are found.

• A slowly decreasing failure rate may mean that the product is poorly designed and expensive to fix - begging the question as to whether the product should simply be abandoned.

For the bathtub curve and failure rate analysis to be useful tools, the team must first:

• define failures - for software projects, a failure is not just a defect but any unexpected behavior or expected behavior which is not there.  Defining failure rates can be a complex endeavor as no two failures are equal.  Examples of failures: a traditional bug, product failing to scale to the desired number of users, missing critical capabilities, lacking usability, etc.

• track failures - once failures are defined, they need to be diligently tracked in order to have an accurate view of the quality of the product.

One last quick note...

Do you wonder how a software product or platform can experience wear-out failures towards the end of the bathtub curve?

• Quick Answer: Have you used Microsoft Windows on a machine for a long time?

• Longer Answer: One of the biggest reasons for wear-out failures in software products are the rapidly changing needs and expectations of its users.  Consider a smart phone which was created 5 years ago and which still works as well as it did 5 years ago - that is, nothing changed in terms of performance or features.  For today's user - who expects a bigger screen, a faster processor, a longer battery life, more features, less weight - the 5 year old phone is worn-out it has many "failures".

As designers of software products (or any products) our goal is to increase the "useful life" of the product, the period in the middle of the bathtub curve where the defect rate is steady and not increasing.

How can we do that?

Here are some ideas:

• try to anticipate how the needs of the users might change over time,

• design the system to be configurable so that it can be easily changed as the user needs change,

• build extensibility into the platform so that new features and capabilities can be added over time,

• design the system to be modular so that obsolete capabilities can be easily removed or hidden.