In the context of "How can architecture skills help to guide refactorings towards a different design or even architecture?"
Trade-offs:
Especially interesting when discussing the need and/or benefit as well as right timing for "bigger refactorings". With "bigger" I don't refer to bigger steps but rather that the end-result of the many steps implies a bigger restructuring as a whole...
I’d be interested in hearing more about intuition. A lot of my problem solving involves intuition, and I think it’s something I’m good at. I always try to prove if the intuition is right or wrong as soon as I can, but I’d definitely like to hear more about how you trust your own instincts especially in such a technical/analytical environment.
Oct 16, 2023·edited Oct 16, 2023Liked by Kent Beck
At Least Two Contexts
I think it is super important in this industry that someone luminary talk about the obvious differences between programmers working in a business automation context (project), versus programmers working in innovation (product).
The lack of understanding of this difference (that it even exists) is leading to lots of semantic diffusion and confusion about what works best in each context, despite the fact that both use the same tools and languages for very different jobs and contexts, and there is little developer mobility between them.
How do your design ideas and approach align/differ from famous architectures, like hexagonal/onion/clean. And from common design patterns, dependency injection, etc. Do you find them useful or not? Does your interactive approach lead to them eventually?
I’m interested to know more about how local design decisions/tidies bubble up to higher level concepts.
A topic that is widely ignored, but which I think you're uniquely positioned to discuss is: how to deal with inherent complexity. Most essays on complexity are focused on just one thing: reducing incidental complexity. Which is good, but insufficient.
There are very complex systems that need to be written and maintained. I'm part of a team working on a small one now and finding that many of the usual bits of advice only carry us so far. For example, understanding the movement of data through the system, breadcrumbs, capturing the data about the code, expanding code maps, project lexicons/dictionaries, etc. are all techniques that are familiar in the abstract but become very specific and indispensable disciplines on complex systems. However, there is very little info to guide devs except the occasional case history from which it can be difficult to extract specific beneficial practices.
IMHO, this area--working in/on complex systems--would greatly benefit from Beck-quality pragmatic advice. And given your work on large systems early on and at Facebook, you surely have lots to say on this topic that I would really like to read.
I first was introduced to ergodicity in an economic and personal finance context and was really drawn to the concept. I've been enjoying the early thoughts you've been sharing lately.
Timing vs ordering vs velocity and how that relates to productivity. I've been having the productivity argument at work and the McKinsey report didn't help
Why most programmers got into doing this job because they like dealing with things, not dealing with the complexity of people and their emotions.
Then how that leads to them preferring to abdicate responsibility for taking care of "people issues" to other people more skillful at, (who then have to deal with the people problems). Thus not having good tools, or practice, to deal with that conflict later in their vocation?
Then later in their vocation realizing that “people issues” (and their emotions) is the far harder thing to deal with professionally to make it anywhere in their careers, (beyond being an expert beginner at coding in some dark corner of the universe on their own).
The point being that it takes a lot of time and handholding to train them later to care about the people things, while they are learning to take care of the technical things better. Something like that
The entire XP/Agile frame seems to want to forger this word. 20+ years later, what does it mean for modern software practice to work in terms of a manifesto? Why was that necessary? Is it still necessary?
* Intuition - I tend to lean on this very strongly with good success, and I do not see this explored anywhere. I suspect it's experience-based plus systems-thinking, but I haven't seen this anywhere else.
* Trade-offs - I feel this is the most critical ability of senior technology professionals in addition to their technical excellence overall.
Align authority & responsibility. Especially in a startup context, I’d be interested in material about technical leadership without authority.
I would like to learn about:
- Trade off, we are always talking about trade off.
- Architects – in a certain way, related to trade-off and how architectural decisions relate to code level decisions, and vice versa
- Refactoring my way
Refactoring my way - extract & inline:
Would be a great continuation to tidying
Vertical & horizontal
Architects:
In the context of "How can architecture skills help to guide refactorings towards a different design or even architecture?"
Trade-offs:
Especially interesting when discussing the need and/or benefit as well as right timing for "bigger refactorings". With "bigger" I don't refer to bigger steps but rather that the end-result of the many steps implies a bigger restructuring as a whole...
I’d be interested in hearing more about intuition. A lot of my problem solving involves intuition, and I think it’s something I’m good at. I always try to prove if the intuition is right or wrong as soon as I can, but I’d definitely like to hear more about how you trust your own instincts especially in such a technical/analytical environment.
Four Rules. Vertical and Horizontal. Refactoring your way.
Sorry, fairly new here, is book 1 still available?
At Least Two Contexts
I think it is super important in this industry that someone luminary talk about the obvious differences between programmers working in a business automation context (project), versus programmers working in innovation (product).
The lack of understanding of this difference (that it even exists) is leading to lots of semantic diffusion and confusion about what works best in each context, despite the fact that both use the same tools and languages for very different jobs and contexts, and there is little developer mobility between them.
Architects
&
Four Rules
All of them. But if I have to choose:
Timing
Power laws
Align authority & responsibility
Architects
Four Rules
Refactoring my way—extract & inline
I like all those topics.
One I've often heard but never understood is "power laws."
One I fancy is "refactoring your way."
One I don't see in which I'm keenly interested is "system thinking."
I'm eager to learn what timing means here - I've received a few: "You're bringing up things too late/too early, wrong timing!"
How do your design ideas and approach align/differ from famous architectures, like hexagonal/onion/clean. And from common design patterns, dependency injection, etc. Do you find them useful or not? Does your interactive approach lead to them eventually?
I’m interested to know more about how local design decisions/tidies bubble up to higher level concepts.
A topic that is widely ignored, but which I think you're uniquely positioned to discuss is: how to deal with inherent complexity. Most essays on complexity are focused on just one thing: reducing incidental complexity. Which is good, but insufficient.
There are very complex systems that need to be written and maintained. I'm part of a team working on a small one now and finding that many of the usual bits of advice only carry us so far. For example, understanding the movement of data through the system, breadcrumbs, capturing the data about the code, expanding code maps, project lexicons/dictionaries, etc. are all techniques that are familiar in the abstract but become very specific and indispensable disciplines on complex systems. However, there is very little info to guide devs except the occasional case history from which it can be difficult to extract specific beneficial practices.
IMHO, this area--working in/on complex systems--would greatly benefit from Beck-quality pragmatic advice. And given your work on large systems early on and at Facebook, you surely have lots to say on this topic that I would really like to read.
TCR
Ergodicity and refactoring stick out to me.
I first was introduced to ergodicity in an economic and personal finance context and was really drawn to the concept. I've been enjoying the early thoughts you've been sharing lately.
Timing vs ordering vs velocity and how that relates to productivity. I've been having the productivity argument at work and the McKinsey report didn't help
Ergodicity as it applies to software systems. (Could also go with Four Rules, sounds like a great debate right out of the gate).
People versus Things?
Why most programmers got into doing this job because they like dealing with things, not dealing with the complexity of people and their emotions.
Then how that leads to them preferring to abdicate responsibility for taking care of "people issues" to other people more skillful at, (who then have to deal with the people problems). Thus not having good tools, or practice, to deal with that conflict later in their vocation?
Then later in their vocation realizing that “people issues” (and their emotions) is the far harder thing to deal with professionally to make it anywhere in their careers, (beyond being an expert beginner at coding in some dark corner of the universe on their own).
The point being that it takes a lot of time and handholding to train them later to care about the people things, while they are learning to take care of the technical things better. Something like that
> Manifesto
This word.
The entire XP/Agile frame seems to want to forger this word. 20+ years later, what does it mean for modern software practice to work in terms of a manifesto? Why was that necessary? Is it still necessary?
* Intuition - I tend to lean on this very strongly with good success, and I do not see this explored anywhere. I suspect it's experience-based plus systems-thinking, but I haven't seen this anywhere else.
* Trade-offs - I feel this is the most critical ability of senior technology professionals in addition to their technical excellence overall.