I started reading https://technologyconversations.com/2013/12/20/test-driven-development-tdd-example-walkthrough/ and got to the subheading "Requirement 2: For an empty string the method will return 0" yesterday.  I like their example, which is an "add" function. It shows the potential issue that even a simple sounding feature could have a bunch of smaller requirements that can be all too easy to conglomerate into larger but more descriptive requirements. Now, after sleeping on it, I've come to the conclusion that this might be a realistic way of getting progress done on projects like #SecSavr [gd0036].

The Deliverable

I plan projects based on the "deliverable" that Me In The Past requested. This is similar to starting at the end of a maze and drawing a line to the start. In this case, it is me mentally simulating what it would've been like in an alternate reality where I bought my project as a kit. I know that there is a high chance that the deliverable would still need refinement, just like buying a product and voicing suggestions for improvements, and so the main goal is to reduce the chance of having to start from square one because the deliverable that Me In The Past requested isn't what Future Me now requires. 

Eventually, I'd converge on a project solution such that the only way I'd properly compute a new solution is if the deliverable of the current solution was insufficient (in other words, going back to the drawing board because the prototype failed). Even if the deliverable works, I know that the probability of a perfect design first try is very low.

Relating to Test Driven Development

Thinking about this, it just seems that I'm just doing 1 large (and therefore complex) test case instead of what was suggested in the article: creating 1 test case from 1 requirement (that fails since nothing has currently been designed), designing to fit that test case only, passing the test case and moving onto the next one.

Now I need to think about the way to order the requirements to reduce the chance of a large refactor effort down the line yet still have the easier requirements closer to the top. Fusion 360 (and especially FreeCAD that is tackling the Topological Naming Problem for the future 1.0 release {I wasn't expecting them to ever get a 1.0 out for decades}) isn't very friendly when it comes to CAD refactoring (and is paritially the reason why I'm researching my options of writing my own CAD software in #enSweepen [gd0096]). In the present day, this and the desire to limit the filament consumption for 1-off prototypes due to cost and the environment means that my interest to reduce refactoring works against getting prototypes and tests out more frequently. 

There's obviously a balance somewhere in there. Right now I'm likely too far on the "reduce refactoring" side of the spectrum to productively and consistently progress in my projects and will try to compute a new solution to this problem that incorporates ideas from Test Driven Development.