Red Green Repeat Adventures of a Spec Driven Junkie

Kent Beck's 3X and Software Tests

I had a chance to hear Kent Beck talk about his newest idea: 3X at ThoughtWorks. Link to Video I really enjoyed the talk as it brought together quite a few thoughts I have about software, business, and tests. It also puts into perspective one thought I have had from @patio11’s ReTweet:

Overview of 3X

Diagram of 3X with respect to time and payoff:

kent beck 3x diagram

  • Explore phase is trying out new things and finding product-market fit. It’s very slow and payoff is very low.
  • Expand phase is when there is traction with a product or company. This phase is about scaling product supply while meeting market demand. Everything in this phase just grows exponentially. This is the upward trend at the end of the hockey stick curve, where every start up wants to be.
  • Extract phase is the final phase for a company or product, where companies are maximizing profit of product and its associated market. Large estabilished companies are usually in this phase.

Overall, 3X gives a general overview of almost any company or product:

  • Startups are usually in the Explore phase.
  • Funded startups in their later stages have reached the Expand phase.
  • Big companies are in the Extraction phase.

I like the 3X model since it is a framework which I can talk about a company and a product interchangeably.

3X and Software tests

Now, Kent Beck is infamous for introducing Agile and Software testing. Where do software tests fit in the 3X model? This is how he explained software tests in each phase of 3X:

Stage Tests?
Explore No need for tests
Expand Start to introduce tests
Extract Tests are required

“No need for tests” - woah, this is such a deviation from what Kent is famous for. Let’s look at each phase in more detail.


Explore phase software doesn’t need to have tests. The product is still in its infancy, the market is the ultimate test. If the market does not want the product, the product will be rejected.

One can just write code, toss it out to the market and if it gets more interest, then build on the code. The feedback loop is the market and the market is not well defined, but pass/fail is well defined.

Tests will just slow down exploration because the market is the one testing the code. Having software tests adds another barrier to success. There is no need to have another barrier at this stage.


Expand phase software can be written on top of explore phase software, but in terms of business, the product should start to be tested, especially along the product path, which was defined by the explore phase.

Introducing tests here is the best. The market expects the product to behave in a consistent way. This consistency can be guaranteed with tests.


Extract phase is about efficiently extracting value from the market. A great way to ensure that is to have tests to make sure any product changes do not interfere with current extraction and enhances extraction, even if it’s very little.

Tests help with the extraction phase by making sure changes are consistent with the market’s understanding of the company’s product. Engineering is more efficient with tests since it models the customer in software.

Tests are required in this phase for a company to successfully extract from the market.


So, Kent introduced test first to the world… and with 3X introduces tests are not always needed. Two very important thoughts depending on the situation.

For me, 3X connects software, business, and tests in a holistic manner, while putting tests in the right perspective in the lifetime of a company.

Having software tests early on in the life of a business will be a waste. There is no product consistency because there is no customer. Consistent with patio11’s re-tweet.

Having software tests later in the life of a business will bring value because the tests keep the product consistent for the customer, allow maximize profit extraction from the customer.

Ultimately, software tests don’t guarantee business success, but business consistency. 3X shows when software tests should be introduced.

Go Forth, and test (when needed!)