IEEE Software - The Pragmatic Designer: Two Kinds of Iteration

This column was published in IEEE Software, The Pragmatic Designer column, January-February 2022, Vol 39, number 1.

ABSTRACT: There are two kinds of iteration, but they are commonly conflated. The first is the evolution of a design and its implementation to become more suitable over time: design-focused iteration (DFI). The second is the evolution of an artifact (like code) to become more suitable over time: code-focused iteration (CFI).

CFI improves only the code and ignores the refinement relationship between design and code. In contrast, a goal of DFI is nurturing and improving the refinement relationship so that the design becomes more stable and valuable over time.

Refactoring happens in both kinds of iteration. In CFI, the refactoring is shallow and textual. In DFI, the refactoring is conceptual and yields what Domain Driven Design calls “deep models” and “supple designs”.

In the allegory of the cave, Plato argued that invisible concepts, such as geometry, could be more true than any figures that we imperfectly scratch in the sand. The triangles and squares that we can observe with our eyes are just shadows cast on the wall of a cave by the pure ideas that we cannot observe directly. This presents us with a choice: should we fixate on the shadows we can see, or use them to discover hidden truths?

Today, two and a half millennia after Plato wrote his allegory, software developers make that same choice. Some developers see source code as the truth. Others see source code as the shadow on the wall that provides clues about the truth, which is the problem and solution that cannot be observed directly. I doubt Plato would be surprised that we are still debating.

Many developers consider themselves as pragmatic and therefore decide that seeking invisible truth is something left for philosophers and academics. I disagree. The Wright brothers were deeply pragmatic, yet in their quest to be the first to fly they both built airplanes and developed theories about aviation. They built an airplane before others precisely because they pursued both.

Importantly, the Wright brothers used an iterative approach. Iterations forced them to build something instead of spending all their time on philosophy. Iteration is what makes it possible, and indeed pragmatic, for engineers to both get things working and seek the invisible truths that explain how to make things work better.

Here’s the rub: Iteration means different things to different people. “Code is the truth” developers iterate on the code, adding features over time. I call this code-focused iteration (CFI). “Shadow on the wall” developers iterate on their understanding and on the code, making both better over time. I call this design-focused iteration (DFI).

Because the word “iteration” is ambiguous, developers can declare “we are iterating” and yet be doing quite different things. Small changes in day-to-day activities lead to different outcomes after just a few months. Developers doing code-focused iteration erode their designs, impair their readiness for the next requirement, and reduce their productivity. In contrast, developers doing design-focused iteration strengthen their design with each iteration, solve their problems better, and enjoy their work.

… The rest will be available when published in January 2022.


  1. W. Cunningham, The WyCash Portfolio Management System, in Proc. OOPSLA 92, Vancouver, Canada, Oct. 5–10, 1992. doi: 10.1145/157709.157715.
  2. D. D’Souza and A. C. Wills, Objects, Components, and Frameworks with UML: The Catalysis Approach. Boston: Addison-Wesley, 1998.
  3. M. Keeling, T. Halloran, G. Fairbanks, Garbage Collect Your Technical Debt, IEEE Software, vol 38, no. 5. Sept.-Oct. 2021. DOI Bookmark: 10.1109/MS.2021.3086578.
  4. G. Fairbanks, The Rituals of Iterations and Tests, IEEE Software, vol. 37, no. 6, pp. 105–108, Nov.–Dec.2020. doi: 10.1109/MS.2020.3017445.
  5. E. Evans, Domain-Driven Design, Addison-Wesley, 2004.