Congrats on getting close to complete! I'll be interested to see what you might be able to come up with on the possible "Data" chapter. Lately I've been thinking a lot about the Stack Overflow survey https://stackoverflow.blog/2022/03/17/new-data-what-makes-developers-happy-at-work/ that called out "Lack of productivity" as the #1 factor that predicted developers being unhappy at work. I definitely feel this myself when I have a week where I'm not getting as much done as I hope, but I wouldn't have predicted that type of unhappiness would outweigh "work/life balance" and the rest. It seems like a possibly interesting applications of data could be to help affirm when a productive week is happening, even if it's just in the backend or API, where there is little visual manifestation of progress.
Many of the chapters you've completed so far feel like they create a recipe for a faster-moving team, but if it's not possible to measure how much improvement might be possible by following the methods, then the utility to our team would be lower. Easier said than done to compare velocity of a repo w/ and w/o tidying, but to the extent it is possible it makes the suggestions more persuasive.
I understand the desire to quantify, but measurement itself is an intervention with unpredictable & unintended consequences. Rather than try to measure a priori I recommend people try it & see if it feels different. If it doesn't, or if it feels worse, discontinue immediately.
Put another way, I don't think measurement is terribly persuasive. Lack of measurement is used as an excuse to maintain the status quo. And this will never be science. There are too many confounding factors for that.
As the next book will be about the team, and if my memory serves the third would be about the organisation at large, I'm thinking flow. Like inedibill mentioned in a previous comment one of the main frustrations for many is lack of productivity. I've found that this is mostly caused by a lack of flow. Tidying is a way to increase flow of change, just as TDD is. But scaling this to the team and to the organisation is a different ballgame altogether. XP is certainly a way to go. I'm sort of thinking it would be nice to get more of that sort of stuff. What works, what doesn't, how to introduce, I don't know. Somewhere there. In some form. With or without references to XP as such. In the same conversational style you usually use (that I absolutely love by the way :) ).
Thank you so much Mr. Kent Beck! I am eagerly looking forward to the books and I am sure I will enjoy them a lot!
The place I am struggling with is being able to visualize the entire system that I am changing, and ensuring I am testing all the affected interactions. Frequently, I forget to test some remote system interaction which is being affected by my change, or find it too late. It is becoming more and more difficult as I progress in my career as the changes I am making are becoming more widespread.
Is there any way, apart from sheer diligence, that I can trick myself into producing high quality, but large-ish changes in the system?
Congrats on getting close to complete! I'll be interested to see what you might be able to come up with on the possible "Data" chapter. Lately I've been thinking a lot about the Stack Overflow survey https://stackoverflow.blog/2022/03/17/new-data-what-makes-developers-happy-at-work/ that called out "Lack of productivity" as the #1 factor that predicted developers being unhappy at work. I definitely feel this myself when I have a week where I'm not getting as much done as I hope, but I wouldn't have predicted that type of unhappiness would outweigh "work/life balance" and the rest. It seems like a possibly interesting applications of data could be to help affirm when a productive week is happening, even if it's just in the backend or API, where there is little visual manifestation of progress.
Many of the chapters you've completed so far feel like they create a recipe for a faster-moving team, but if it's not possible to measure how much improvement might be possible by following the methods, then the utility to our team would be lower. Easier said than done to compare velocity of a repo w/ and w/o tidying, but to the extent it is possible it makes the suggestions more persuasive.
I understand the desire to quantify, but measurement itself is an intervention with unpredictable & unintended consequences. Rather than try to measure a priori I recommend people try it & see if it feels different. If it doesn't, or if it feels worse, discontinue immediately.
Put another way, I don't think measurement is terribly persuasive. Lack of measurement is used as an excuse to maintain the status quo. And this will never be science. There are too many confounding factors for that.
As the next book will be about the team, and if my memory serves the third would be about the organisation at large, I'm thinking flow. Like inedibill mentioned in a previous comment one of the main frustrations for many is lack of productivity. I've found that this is mostly caused by a lack of flow. Tidying is a way to increase flow of change, just as TDD is. But scaling this to the team and to the organisation is a different ballgame altogether. XP is certainly a way to go. I'm sort of thinking it would be nice to get more of that sort of stuff. What works, what doesn't, how to introduce, I don't know. Somewhere there. In some form. With or without references to XP as such. In the same conversational style you usually use (that I absolutely love by the way :) ).
Kent, thanks for sharing your process and work with us. There is much to learn here.
Congrats on getting to this point in writing your new book.
Thank you so much Mr. Kent Beck! I am eagerly looking forward to the books and I am sure I will enjoy them a lot!
The place I am struggling with is being able to visualize the entire system that I am changing, and ensuring I am testing all the affected interactions. Frequently, I forget to test some remote system interaction which is being affected by my change, or find it too late. It is becoming more and more difficult as I progress in my career as the changes I am making are becoming more widespread.
Is there any way, apart from sheer diligence, that I can trick myself into producing high quality, but large-ish changes in the system?
Thank you 🙏
Yes, by never making large changes. If you’re nervous, make smaller changes. No, even smaller than that. 😉