This is the best piece of writing I read this year. I'll be coming back to it to clarify my own thinking.

Expand full comment
Sep 7·edited Sep 7Liked by Kent Beck

1. "Make it work; make it right; make it fast"

2. The Four Rules of Simple Design

3. User Stories: I'm not certain if you originated the term, but I recall hearing you adopt this concept after Ward's "Episode" method. Your early explanation remains my favorite: “I imagined a user grabbing another user in the hallway and saying, ‘I gotta tell you about this wonderful new thing the application does...’ Stories are the stories customers wish they could tell about the system but can’t (yet).”

4. Collective Ownership

5. ATDD*: Whether or not you coined this term (really bad name, BTW), it has been pivotal to my daily work. The concept was later refined to "Specification by Examples" by Gojko.

6. TCR / Limbo: recently when my colleague and I saw the google IDX idea, we were like "wow, Kent's Limbo is coming closer"

7. TPS: My introduction to TPS was through you, and it led me down a 20-year rabbit hole of exploration, providing both deep insights and meaningful friendships. You guided me to the source, bypassing the Western interpretations, unlike the Lean or software Lean.

8. Behaviour - Structure

9. Reversibility


Could you please confirm my understanding of your involvement in User Story? And perhaps also ATDD. Thanks!

Expand full comment

I find value in your abstract, systems behavior explanations, that shed light on real world phenomena, and help make much better sense of what's happening on an uber level, which informs what one can learn from it, or what one can do to take advantage of it.

Expand full comment

My main takeaway is that freedom from oversight requires taking personal responsibility. Which is a good theme in my view.

Expand full comment
Sep 6Liked by Kent Beck

Idea or, better yet your perspective, that affected me, and not mentioned explicitly, is how you look as software as behavior or structure. I usually read books that talk about architecture, design, components, and requirements. You somehow level the field with B-S reasoning. I like that there is more than one view on same problem and value each perspective.

Expand full comment
Sep 6Liked by Kent Beck

Begs for a diagram, or a table.

Expand full comment

I wonder if a graph would summarize it better. although it may not appeal to a marketing coach? Something to make the connections at a higher level than everything to everything? Enjoy your vacation!

Expand full comment

It's really admirable how you shaped software development over the years!

The one thing that struck a chord with me, though, as a software tester in my previous life, is when you say developers able to test their own software with JUnit alleviated the perception that they are untrustworthy.

That really hurt. The message is that developers don't (or shouldn't) need anyone else and that they must be good at everything. That means me, as a tester, is not needed or useful to you. This was the same message I got from Cucumber, though, so it's not just your perspective. With Cucumber the role in question is the Product Owner.

Maybe it's not that we (anyone other than a developer) see the developers are untrustworthy. Maybe it's that they don't trust anyone that isn't the same as them to meaningfully contribute? The underlying problem is not even trust in my opinion, but communication.

Two (diverse) heads are better than one. It is the same reason why you would do pair programming. It's also the same reason why you got a coach and found them valuable.

The difference between good and great software is the diversity of the skills in the team, and how well they work together.

Expand full comment

I don't know if an ontology/classification/categorization would help, and even if so, I don't know if "this" ontology would help, but here is one attempt (said the blind man as he reached for the elephant's leg).



*instance/real thing





business metrics


classification thinkie to aid in understanding/modeling the world (does not say what to do)

* 3X: Explore/expand/extract

* Empirical software design

noun pattern (when building something)

Architecture pattern

Software design pattern

verb pattern (to guide behavior)

best practice

* Make it work; make it right; make it fast (from comment below)

individual rule of emergent system


* Refactoring

sets of thinkies

pattern languages

* Alexander's architecture pattern language

* software design patterns

sets of best practices

emergent rule-based systems - complex behavior from a set of simple rules

agile programming

* extreme programming

* scrum

* all the many modern variants



Expand full comment

Yeah, I generated a diagram based on what listed here (thanks for ChatGPT and Mermaid.live) https://substack.com/profile/8826772-juntao-qiu/note/c-39691000?utm_source=notes-share-action&r=596s4 it's a bit easier to read the visualisation I suppose.

Expand full comment