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!
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.
I think that’s a key point I haven’t gotten across well. I am suggesting people take more responsibility but also showing them how better to take responsibility. It would be overwhelming if working the old way.
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.
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.
There's a lot here. First, thank you for this. We are all figuring out how our abilities & perspectives can contribute to software development. And those abilities & perspectives keep changing.
There's a class of error, where the program doesn't do what the programmer thinks it should do, that used to be very common. Testers are not needed to catch those errors any more. There are plenty more errors to catch. A mature team will make sure they catch those error (see Whole Team from XP Explained 2nd ed).
I think we agree on the need for diversity. I'm not sure how you personally fit into development, but that's a function of you & also your team's needs. I wish I had a more reassuring answer.
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).
========================
class/category
*instance/real thing
========================
empiricism
math
science
business metrics
thinkies
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
* TDD
* 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
This is the best piece of writing I read this year. I'll be coming back to it to clarify my own thinking.
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!
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.
Also how it can apply to other systems
My main takeaway is that freedom from oversight requires taking personal responsibility. Which is a good theme in my view.
Also that partnerships help lighten the load of responsibility.
I think that’s a key point I haven’t gotten across well. I am suggesting people take more responsibility but also showing them how better to take responsibility. It would be overwhelming if working the old way.
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.
Begs for a diagram, or a table.
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.
There's a lot here. First, thank you for this. We are all figuring out how our abilities & perspectives can contribute to software development. And those abilities & perspectives keep changing.
There's a class of error, where the program doesn't do what the programmer thinks it should do, that used to be very common. Testers are not needed to catch those errors any more. There are plenty more errors to catch. A mature team will make sure they catch those error (see Whole Team from XP Explained 2nd ed).
I think we agree on the need for diversity. I'm not sure how you personally fit into development, but that's a function of you & also your team's needs. I wish I had a more reassuring answer.
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).
========================
class/category
*instance/real thing
========================
empiricism
math
science
business metrics
thinkies
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
* TDD
* 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
invention
*JUnit
It ate my tabs!!! Here it is with spaces.
========================
class/category
*instance/real thing
========================
empiricism
science
business metrics
thinkies
classification thinkie to aid in understanding/modeling the world
* 3X: Explore/expand/extract
* Empirical software design
noun pattern (when building something)
Architecture pattern
Software design pattern
verb pattern (to guide behavior)
best practice
individual rule of emergent system
* TDD
* 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
invention
*JUnit
Last try with dots
========================
class/category
*instance/real thing
========================
empiricism
....science
....business metrics
....thinkies
........classification thinkie to aid in understanding and modeling the world (these do not tell you what to do)
............* 3X: Explore/expand/extract
............* Empirical software design
........noun pattern (when building something)
............Architecture pattern
............Software design pattern
........verb thinkie (to guide behavior)
............best practice
............individual rule of emergent system
................* TDD
................* 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
invention
....*JUnit
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.