Sunday, April 25, 2021

TDD: When the API changes

If I discover my API is bad after writing 60 tests, I have to change a lot! -- shared by James Grenning

My experience with the TDD literature is that it tends to concentrate of situations that are fixed.  Here's a problem, implement a solution in bite sized steps, done.

And to be fair, in a lot of cases -- where the implications of "bite sized steps" are alien, that's enough.  There's a lot going on, and eliminating distractions via simplification is, I believe, a good focusing technique.  Red-Green-Refactor is the "new" idea, and we want to keep that centered until the student can exercise the loop without concentration.

But -- if we intend that TDD be executed successfully outside of lessons -- we're going to need to re-introduce complicating factors so that students can experience what they are going to face in the wild.

Wednesday, April 21, 2021

I was reading Brian Marick's write up of his experience with Hillel Wayne's budget modeling experiment.

Toward the end of the exercise, Marick writes:

I decided to write an affordability function that would call the same functions as can_afford? but return rich results instead of funneling all the possibilities into true or false....  Then I wrote can_afford? in terms of affordability.

I've seen this pattern a number of times recently.  It came up during a transport tycoon exercise,  where I started exploring the idea of generating a complete report of a simulation, and then extracting from that report the answer to the simple question.

Before that, it appeared when I started using kitchen sink logging in my AWS Lambda functions; the event handler produces a record of all of the information it has collected along the way, one field of which is "the answer".  The log entry for the request get a detailed document of all of the (not secret) information, and we can later carve that information into smaller pieces.

What the pattern reminds me of is STEM exams in high school; writing out the derivation of the answer long form, with the final calculation circled at the bottom.  The motivation is, I think, much the same; the view of the intermediate calculations is an important diagnostic tool when the final answer indicates a fault.

GeePaw Hill has recently been discussing the Made application and the Making application.  The Made application provides narrow, targeted affordances, designed to delight the end user who pays the bills.  But the purpose of the Making application is delightful (cost effective) making, where the human in the loop has different concerns.

Injecting the Making into the Made gives us, perhaps, the best of both worlds.

I also see similarity between this idea and Ward Cunningham's early description of technical debt; the underlying report is going to be more closely aligned with how we think about the domain than the simple distillation of the answer, and with the long form design in place, we have code that is aligned with the business, and should be easy to change when the business expects the code to be easy to change.