# Common Misconceptions about Agile Design

> John Ousterhout criticized agile design and test-driven development in a YouTube conversation, but I think it is less a matter of a fundamental difference of opinion than a straw man criticism arising from misunderstanding. The content of the criticism is not very different from Chapter 19 of his own book, The philosophy of software design. This conversation seems to reveal several common misconceptions about agile design quite well, so I tried organizing them here.

<John Ousterhout> criticized [agile design](https://wiki.g15e.com/pages/Agile%20software%20design.txt) and [test-driven development](https://wiki.g15e.com/pages/Test-driven%20development.txt) in a [YouTube conversation](https://www.youtube.com/watch?v=lz451zUlF-k), but I think it is less a matter of a fundamental difference of opinion than a <straw man criticism> arising from misunderstanding. The content of the criticism is not very different from Chapter 19 of his own book, <The philosophy of software design>. This conversation seems to reveal several common misconceptions about agile design quite well, so I tried organizing them here.

(<June 12, 2025> <Kent Beck> also appears on the same channel and [responds](https://www.youtube.com/watch?v=aSXaxOdVtAQ) to the criticism above.)

## If you do TDD, you do not design

The author argues that TDD is nothing more than writing tests and implementing them one by one, and that this approach not only cannot produce a good design but actually gets in the way of design.

But this is a misunderstanding of TDD. The process of writing tests is necessarily accompanied by design (thinking from the client's point of view about what functions a given module should have, what its interface should look like, and so on), and the process of [refactoring](https://wiki.g15e.com/pages/Refactoring.txt) after the tests pass is also design.

Still, one might regard design done in small test-sized units, or design arrived at by refactoring small pieces of code, as too trivial. But this, too, is based on another misconception: that "TDD at the smallest scale is the whole of TDD."

## TDD at the smallest scale is the whole of TDD

Many practices in agile methodology are designed with a <fractal structure>, and TDD is no different. At the smallest scale, the practice of writing test code first and then producing implementation code that satisfies it is the same, at a larger scale, as the [Pull system](https://wiki.g15e.com/pages/Pull%20system.txt) of lean production, in which software features are induced by market demand. If at the small scale there is a "green bar," then at the large scale there is "creating business value."

At the intermediate level there is <ATDD>. It is a way of first writing high-level acceptance tests for a <user story>. [Ward Cunningham](https://wiki.g15e.com/pages/Ward%20Cunningham.txt)'s [Framework for integrated test](https://wiki.g15e.com/en/pages/Framework%20for%20integrated%20test.txt), created in <2002>, is an automated ATDD framework.

Put this way, it might seem as though there were nothing between "TDD at the smallest scale" and "ATDD at the intermediate level," but that is not so. The reason [Test-driven development: by example](https://wiki.g15e.com/pages/Test-driven%20development%20-%20By%20example.txt) showed a "short stride" is not because that stride is exemplary, but because only by becoming familiar with the shortest stride can you vary your stride in many ways. Yet many people often mistake only the shortest-stride TDD for TDD done properly. (See: [Stride length of the TDD cycle](https://wiki.g15e.com/pages/Stride%20of%20TDD%20cycle.txt))

## Agile methodology does not do upfront design

There is another misconception in a similar category: the misconception that agile methodology does not do upfront design. Agile methodology always does upfront design. The only thing agile methodology opposes is bloated upfront design (BIG upfront design or BIG design upfront).