From d7c6bea7fabcbe419134c8aacede620ec0ff4e6f Mon Sep 17 00:00:00 2001 From: Firehose Bot Date: Mon, 27 Jul 2026 11:14:22 +0100 Subject: [PATCH] good enough for now --- .../engineering/2026/07-27-swim-the-test.md | 43 +++++++++++++++++-- 1 file changed, 39 insertions(+), 4 deletions(-) diff --git a/app/priv/blog/engineering/2026/07-27-swim-the-test.md b/app/priv/blog/engineering/2026/07-27-swim-the-test.md index bd49ab3..98e5f79 100644 --- a/app/priv/blog/engineering/2026/07-27-swim-the-test.md +++ b/app/priv/blog/engineering/2026/07-27-swim-the-test.md @@ -66,15 +66,50 @@ This looks like a lot of work, and I haven't integrated this in an application. I am trying to draw in the users as well, let's see how this goes. -Further Reading +Further, further, Reading ==== This is meta - a Further Reading section in a further reading post ;-). -[A Harness for Behaviour: Ensuring Ai-generated Code Does What We Want - TDD in the Age of AI ](https://www.youtube.com/watch?v=3tdmoj35HG0) -I was reminded of the swim system by this talk of Matteo Vaccari on youtube which focuses on tests that are understandable by the stakeholders. He referenced Fit and focuses on writing tests that work as a communication medium between users, stakeholders and developers. He uses an external DSL in YAML. I am not against YAML, but someoone's remark last year that all new programming languages appear to be YAML gives me pause, whenever I see it. The main thing is when it works it works. Context is key. (not further reading: I ended up with an internal DSL and screenshots in small steps as a medium - the users don't need to be able to write tests, yet, communication about what we are building and how it works is key. In small steps - I don't believe good UX comes from large batches). [LinkedIn post on Matteo's account](https://www.linkedin.com/posts/matteovaccari_the-video-of-my-presentation-at-platmosphere-share-7478330775579586560-vSoX) in case you want to comment. +A harness for behaviour +---- +I was reminded of the swim system by this talk of Matteo Vaccari on youtube which focuses on tests that are understandable by the stakeholders. +[A Harness for Behaviour: Ensuring Ai-generated Code Does What We Want - TDD in the Age of AI ](https://www.youtube.com/watch?v=3tdmoj35HG0) + He referenced Fit and focuses on writing tests that work as a communication medium between users, stakeholders and developers. He uses an external DSL in YAML. I am not against YAML, but someoone's remark last year that all new programming languages appear to be YAML gives me pause, whenever I see it. The main thing is when it works it works. Context is key. (not further reading: I ended up with an internal DSL and screenshots in small steps as a medium - the users don't need to be able to write tests, yet, communication about what we are building and how it works is key. In small steps - I don't believe good UX comes from large batches). [LinkedIn post on Matteo's account](https://www.linkedin.com/posts/matteovaccari_the-video-of-my-presentation-at-platmosphere-share-7478330775579586560-vSoX) in case you want to comment. + +Matteo blogged about this earlier: +[Acceptance tests for AI Assisted development](https://matteo.vaccari.name/posts/acceptance-tests-for-ai-assisted-development/) on "grey box testing". Refers to [Approved Fixtures Pattern](https://lexler.github.io/augmented-coding-patterns/patterns/approved-scenarios/) and is also worth reading on its' own. + +Visible Workings +--- [Visible Workings]( https://web.archive.org/web/20110202132102/http://visibleworkings.com) on archive.org, as the original site is no longer active. I like the notion of "Tinkerable Software". -[Acceptance tests for AI Assisted development](https://matteo.vaccari.name/posts/acceptance-tests-for-ai-assisted-development/) on "grey box testing". Refers to [Approved Fixtures Pattern](https://lexler.github.io/augmented-coding-patterns/patterns/approved-scenarios/) and is also worth reading on its' own. +>Explanatory software goes hand in hand with tinkerable software because the dedicated amateur will need explanations to do the tinkering well. + + +"View Source" +---- + +A comment in one of Jon Udell's posts about 'View Source' reminded me of the work of [Sue Smith](https://www.sue.codes/) My timebox is up, she has a great blog in which is she writes about building tools in an IDE to make software development accessible to newcomers. I remember her writing about how to replicate the 'view source' experience of early web 2.0, where you could find out how a web front-end worked by 'just' viewing the source. + +[What comes after view source?](https://www.sue.codes/blog/afterviewsource/) + +[Being intentional about friction](https://www.sue.codes/blog/whatfriction/) is more tangential, and inspiring. Some comment about the link to the tests in an application on one of Jon Udell's 'swim' posts may be related. That link to the tests inside an application dialog may be seen as friction, but also, as Sue puts it: + +> Removing friction does not necessarily empower people + +and + +> Being able to choose which details are worth paying attention to is the trick. + +Happy reading and watching +==== + +Thank you for making it to the end. I hope this inspires you to do more reading, watching, and more importantly, building. + +As [Steve Freeman put it just now](https://mastodonapp.uk/@sf105/116991301858959311): + +> ward and Bjorn’s “swimlanes” work for the Eclipse foundation was an inspiration. It’s a crime against software that it was left derelict. +