If your Product Owner can't read and understand your tests, you're not done refactoring.
Better yet: write your tests with your Product Owner in the ensemble. They don't have to program, but they can do everything else a member of the ensemble would do.
A well-written test -- indeed habitable code in general -- should primarily use language from the domain, and should be structured so that it tells the same story that your Product Owner would tell.
Can your Product Owner read and understand your tests?
When was the last time your team did multi-disciplinary test-driven development?
“Can your Product Owner read and understand your code?” 👈🏾 is gold!
Myself and the engineers on my team have not thought of the readability of our code from the Product Owner perspective. Currently, we have only been asking is our code “readable” and “understandable” for other engineers.
I am going to take this back to my team and try it out this week!
Hi Kevin, very nice article! I never thought of the 4 rules this way, from the pov of what to do on a codebase that’s not up to spec; but of course that’s the situation we’re in whenever we get to “refactor” in the tdd cycle. I will use this framing in my upcoming training!
If your Product Owner can't read and understand your tests, you're not done refactoring.
Better yet: write your tests with your Product Owner in the ensemble. They don't have to program, but they can do everything else a member of the ensemble would do.
A well-written test -- indeed habitable code in general -- should primarily use language from the domain, and should be structured so that it tells the same story that your Product Owner would tell.
Can your Product Owner read and understand your tests?
When was the last time your team did multi-disciplinary test-driven development?
glad you mention the 4 rules of simply design. I think that's something unknown for most developers but deserves to much more attention.
I totally agree Lars.
And you're going to love what I have planned in a few weeks!
“Can your Product Owner read and understand your code?” 👈🏾 is gold!
Myself and the engineers on my team have not thought of the readability of our code from the Product Owner perspective. Currently, we have only been asking is our code “readable” and “understandable” for other engineers.
I am going to take this back to my team and try it out this week!
Thanks for the great read and insight!
That's great Tatiana -- please let us know what happens!
Hi Kevin, very nice article! I never thought of the 4 rules this way, from the pov of what to do on a codebase that’s not up to spec; but of course that’s the situation we’re in whenever we get to “refactor” in the tdd cycle. I will use this framing in my upcoming training!
Yes @Matteo, I think the 4 rules are a _process_ more than a static description of the code's quality.