Stanford professor John Ousterhout explains why thoughtful software design matters more than ever as AI tools transform coding practices and developer workflows.
Love John's book, but a lot of his views on TDD definitely come across as someone that's only experienced it as "writing unit tests test first" rather than designing APIs and the outer edges of modules test first - which ironically achieves exactly what he thinks TDD is lacking.
On TDD: I think it doesn't have to be so tactical as outlined. It's big benefit is focusing on the minimal need. It's pitfall is not doing refactoring before and after, because that's what's going to drive architectural and design thinking. Initial refactoring, after writing the test, asks the question of "How should the code look like so that I can implement the test as naturally as possible". Refactoring after implementing the test should ask "How can we improve by looking at areas of code that weren't directly touched by implementing this test/feature".
On TDD: I think it doesn't have to be so tactical as outlined. It's big benefit is focusing on the minimal need. It's pitfall is not doing refactoring before and after, because that's what's going to drive architectural and design thinking. Initial refactoring, after writing the test, asks the question of "How should the code look like so that I can implement the test as naturally as possible". Refactoring after implementing the test should ask "How can we improve by looking at areas of code that weren't directly touched by implementing this test/feature".
Looking forward to this episode a lot! Especially because I can take what I read over at Kent Beck's newsletter and try to debate in his voice in my head :D
On a practical note, before starting the podcast, I went through the derived article and found the format a bit confusing (summary 1 - linear list of topics - summary 2).
Thinking about it more I believe it could be improved by inlining the Timestamps into the following Summary section, would that be practical?
Love John's book, but a lot of his views on TDD definitely come across as someone that's only experienced it as "writing unit tests test first" rather than designing APIs and the outer edges of modules test first - which ironically achieves exactly what he thinks TDD is lacking.
I am a simple man. I see "John Ousterhout", I hit "like".
Definitely agree with decomposition. Love your work and the guests. Keep them coming.
On TDD: I think it doesn't have to be so tactical as outlined. It's big benefit is focusing on the minimal need. It's pitfall is not doing refactoring before and after, because that's what's going to drive architectural and design thinking. Initial refactoring, after writing the test, asks the question of "How should the code look like so that I can implement the test as naturally as possible". Refactoring after implementing the test should ask "How can we improve by looking at areas of code that weren't directly touched by implementing this test/feature".
On TDD: I think it doesn't have to be so tactical as outlined. It's big benefit is focusing on the minimal need. It's pitfall is not doing refactoring before and after, because that's what's going to drive architectural and design thinking. Initial refactoring, after writing the test, asks the question of "How should the code look like so that I can implement the test as naturally as possible". Refactoring after implementing the test should ask "How can we improve by looking at areas of code that weren't directly touched by implementing this test/feature".
Looking forward to this episode a lot! Especially because I can take what I read over at Kent Beck's newsletter and try to debate in his voice in my head :D
On a practical note, before starting the podcast, I went through the derived article and found the format a bit confusing (summary 1 - linear list of topics - summary 2).
Thinking about it more I believe it could be improved by inlining the Timestamps into the following Summary section, would that be practical?