The Agile approach to software design

[Zach Tellman]

Hi, since there's been a fair bit of interest in the discussion between Ousterhout and Martin, I thought it was worth providing a bit of historical context for how Martin, and the Agile community as a whole, approaches software design.  Apologies if this is better suited for the existing thread on the discussion, but it seems like the discussion there is more focused on the nuts and bolts of Martin's code.

For context, I've been working on my own book on software design, and in the course of my research have read quite a bit of the existing literature.  I've been especially interested in the Agile literature, since much of it seems to disclaim any need for a formal design practice, and instead gestures towards some sort of emergent design that results from keeping your code tidy.

It turns out, however, that this wasn't always the case.  In the first edition of Kent Beck's Extreme Programming Explained, he had a positive vision for how software design, largely centered around metaphors.  In Martin's own history of the Agile movement, he says:

> In the years just before and after the signing of the Agile Manifesto, the Metaphor practice was something of an embarrassment for us because we couldn't describe it. We knew it was important, and we could point to some successful examples. But we were unable to effectively articulate what we meant. In several of our talks, lectures, or classes, we simply bailed out and said things like, "You'll know it when you see it."

As a result, the Agile community stopped talking about software design.  All mention of it was erased from the second edition of Beck's book, and other leaders in the community began to go out of their way to explain why design was a non-issue.  This statement by Ron Jeffries, for instance, will be familiar to anyone who read Martin's thoughts on comments:

> The source code is also the ONLY document in whatever collection you may have that is guaranteed to reflect reality exactly. As such, it is the only design document that is known to be true. The thoughts, dreams, and fantasies of the designer are only real insofar as they are in the code.

If this is an interesting rabbit hole for any of you, I'd encourage you to read a trio of my recent posts:

* In "the death of the architect", I talk about the failure of Beck's concept of lightweight design
* In "the sudoku affair", I analyze Ron Jeffries' attempt to apply his anti-design methodology to a Sudoku solver
* In "complexity as entropy", I talk about Martin's Clean Code, and the broader use of the broken window metaphor in the Agile literature

Happy to discuss all of this further, if anyone has thoughts or questions.

Zach

[Paul Becker]

What do you mean by 'design'?

I'll offer my understanding. Design is the process of choosing which elements to put together. As such, design happens at all levels and times in a project---from the planning/vision phase where we are operating very abstractly ("I want a calculator that can also make a cup of coffee"), to the combination of libraries and algorithms (in the physical metaphor, choosing the shapes and materials), the features and layout of the user interface, making changes to an existing system (what am i removing? what am i adding? how will these things live together in a new way?), all the way down to writing individual pieces of code (selecting which language elements to put together to create the intended effect). It is through the iteration of design and testing that we discover what is possible, and that we create.

paul

--
You received this message because you are subscribed to the Google Groups "software-design-book" group.
To unsubscribe from this group and stop receiving emails from it, send an email to software-design-...@googlegroups.com.
To view this discussion visit https://groups.google.com/d/msgid/software-design-book/d4b2bdb1-2903-48ac-b4c7-26ee80d38eb6n%40googlegroups.com.

[John Ousterhout]

Hi Zach,

Thanks for your email. I have a couple of comments:

* I like your "complexity as entropy" analogy. One of my favorite sayings is "The First Law of Software Thermodynamics is that software systems tend towards states of increasing complexity". Also, complexity tends to increase monotonically in software, like entropy in physical systems: it's extremely difficult to reduce complexity once it's present.

* It's hard for me to believe that "keeping your code tidy" (which sounds to me like a low-level and localized approach) will cause a good design to emerge. Good design requires thinking at a much more global level. Once you've got the design, then you should be able to operate locally and independently on the pieces, but it's hard to find the right decomposition without global thinking.

-John-

--

[Zach Tellman]

Hi John, thanks for the comments.

​​Also, complexity tends to increase monotonically in software, like entropy in physical systems: it's extremely difficult to reduce complexity once it's present.

I agree, with some caveats.  When we talk about "bit rot", we're not describing some process intrinsic to the software, but rather the effect of the software remaining stable while the world around it changes.  In my experience, complexity mostly grows in the disjunction between software and its environment, rather than in the software itself.

​ It's hard for me to believe that "keeping your code tidy" (which sounds to me like a low-level and localized approach) will cause a good design to emerge

I'd think it would be difficult for anyone to believe this.  As I argue in "the death of the architect", Martin, Jeffries, et al elevated these low-level concerns because that's what they feel comfortable talking about.  And this, in turn, has led to 20+ years of looking for their keys under the street lamp.

Since I didn't say it before, I really appreciate you taking the time to have the conversation with Martin, and document the results.  It's a very interesting (and revealing) artifact.  

Best,

Zach

On Wed, Mar 19, 2025 at 4:04 PM, John Ousterhout <ous...@cs.stanford.edu> wrote:

Hi Zach,

Thanks for your email. I have a couple of comments:

* I like your "complexity as entropy" analogy. One of my favorite sayings is "The First Law of Software Thermodynamics is that software systems tend towards states of increasing complexity". Also, complexity tends to increase monotonically in software, like entropy in physical systems: it's extremely difficult to reduce complexity once it's present.

* It's hard for me to believe that "keeping your code tidy" (which sounds to me like a low-level and localized approach) will cause a good design to emerge. Good design requires thinking at a much more global level. Once you've got the design, then you should be able to operate locally and independently on the pieces, but it's hard to find the right decomposition without global thinking.

-John-

On Fri, Mar 14, 2025 at 7:27 PM Zach Tellman <ztellman@gmail.com> wrote:

Hi, since there's been a fair bit of interest in the discussion between Ousterhout and Martin, I thought it was worth providing a bit of historical context for how Martin, and the Agile community as a whole, approaches software design.  Apologies if this is better suited for the existing thread on the discussion, but it seems like the discussion there is more focused on the nuts and bolts of Martin's code.

For context, I've been working on my own book on software design, and in the course of my research have read quite a bit of the existing literature.  I've been especially interested in the Agile literature, since much of it seems to disclaim any need for a formal design practice, and instead gestures towards some sort of emergent design that results from keeping your code tidy.

It turns out, however, that this wasn't always the case.  In the first edition of Kent Beck's Extreme Programming Explained, he had a positive vision for how software design, largely centered around metaphors.  In Martin's own history of the Agile movement, he says:

> In the years just before and after the signing of the Agile Manifesto, the Metaphor practice was something of an embarrassment for us because we couldn't describe it. We knew it was important, and we could point to some successful examples. But we were unable to effectively articulate what we meant. In several of our talks, lectures, or classes, we simply bailed out and said things like, "You'll know it when you see it."

As a result, the Agile community stopped talking about software design.  All mention of it was erased from the second edition of Beck's book, and other leaders in the community began to go out of their way to explain why design was a non-issue.  This statement by Ron Jeffries, for instance, will be familiar to anyone who read Martin's thoughts on comments:

> The source code is also the ONLY document in whatever collection you may have that is guaranteed to reflect reality exactly. As such, it is the only design document that is known to be true. The thoughts, dreams, and fantasies of the designer are only real insofar as they are in the code.

If this is an interesting rabbit hole for any of you, I'd encourage you to read a trio of my recent posts:

* In "the death of the architect", I talk about the failure of Beck's concept of lightweight design
* In "the sudoku affair", I analyze Ron Jeffries' attempt to apply his anti-design methodology to a Sudoku solver
* In "complexity as entropy", I talk about Martin's Clean Code, and the broader use of the broken window metaphor in the Agile literature

Happy to discuss all of this further, if anyone has thoughts or questions.

Zach

--
You received this message because you are subscribed to the Google Groups "software-design-book" group.

To unsubscribe from this group and stop receiving emails from it, send an email to software-design-book+unsubscribe@googlegroups.com.