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.
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.
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!
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.
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
A Career Accounting
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.
My main takeaway is that freedom from oversight requires taking personal responsibility. Which is a good theme in my view.
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.
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!
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.
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
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.