2 Comments

Hey,

This is also similar to how I approach programming. Incidentally, it's also similar to the steps described in How to Design Programs (https://htdp.org/) and the PPP technique described by McConnell in Code Complete.

Personally, I lean more towards the PPP since it starts by writing in pseudo-code the cases to be covered.

I find that writing in English/pseudo-code helps avoid the particular language mechanics and stay focused on the problem essence.

Rock on, cheers.

Expand full comment
Sep 3·edited Sep 3

Hey Eric, thanks for your article!

What you just described is exactly what we end up achieving with TDD, with the difference that we use tests as a formal method to build and validate the "desired behaviour" (as in agreed-upon user outcomes), step by step, with the very nice side effect of keeping these tests (or runnable specifications, you may say) as means to detect when we unexpectedly break previously defined system behaviour while building new features :)

In the end I'm glad that despite the differences in practices, we share the same understanding and insights of breaking systems down like that!

Expand full comment