Patent registering bodies would have to get back into using prior art to reject patent applications. That used to happen in the 80's and before, but at some point they just gave up and said it could be settled in course cases. When that happens there's room for AIs again to find prior art, etc.

I was at a meetup two weeks ago, and networking with someone two decades younger quite well (commonalities, interests, employer(s), etc), and his face was like I'd pronounced his newborn a being ugly, after I explained what TBD was and why teams do it.

Today, pushing TBD could be considered to be career limiting. I've been thinking about that a lot ...

... Nobody wants to hear that **GitHUB Flow** is just one of three major forms of TBD: trunkbaseddevelopment.com/styles/.

The CollabNet people in the room included a lot of sales veterans of other SCM tools, and there was solid opposition.

This crew and others in the enterprise gave me a clue we were in for an uphill struggle

By contrast, promoting TBD in ThoughtWorks didn't seem so hard, many being converts already

ThoughtWorks's owner had me leave the middle of OSCON in 2005 to present to the sales team at CollabNet in California on how their product (using Svn) could be positioned against ClearCase in the enterprise. I talked about trunk-based development, feature toggles, and keeping it all go-live-able

Those cohorts never heard about TBD before, and branch-crazy feels alluring.

In the early 2000's sales folks for ClearCase, StarTeam and even Perforce would tell enterprises you could do **any** branching model you liked. Even long-running ones.

Some idle thoughts: Comp Sci didn't historically teach branching. Heck, until 15 or so years back, Comp Sci didn't teach source control at all. Quorum in dev teams by sheer numbers is reached quickly for more-recent grads. Such cohorts mostly pick up post-university ways of working from each other.

Stepping away from the "car doppler" React app, and back toward the credit card form and address of the original blog entry: the same test harness ideas for a MacOS app using #SwiftUI and #Appium (via node & JavaScript) to test automate it. paulhammant.com/2025/06/30/s...

And hello NightWatchJS branch and experience :) paulhammant.com/2025/06/25/n...

And a Selenium branch discussed for the same React app and same component-centric tests paulhammant.com/2025/06/22/s...

Continuing the series - a Cypress branch of the same thing (Cypress instead of Playwright for component testing) -> paulhammant.com/2025/06/20/c...

Oh, I think it's there already: github.com/AtRayzor/Dot...

Of course, for enterprise dev life, one would do .NET work in the regular way (solutions, projects and 'dotnet.exe' as your dispatcher for everything applicable). My work here is just an experiment.

The answer could be in Bazel's .NET bindings. I'm familar with Nx's community-made github.com/nx-dotnet/nx... and I think it still uses .sln/.csproj pieces for a canonical test invocation.

I could be in XyProblem territory though - vstest completes but says it could not find compiled-and-in-dll tests. But the diagnostics says "error" around Microsoft.Bcl.AsyncInterfaces.dll that can't be found.

The wall currently is vstest needs Microsoft.Bcl.AsyncInterfaces.dll and that being handed in as a reference, but vstest claiming it can't find it on instantiation.

The very nature of this tree-like way of laying out modules means I've to avoid the .csproj and .sln files. Compile needs to use csc (Roslyn these days) and tests need to go via vstest which /can /take /args for all setup instead of looking for csproj XML or JSON

Techies should've made something for themselves by now .. gist.github.com/paul-hammant.... Linked In's edge over other social media is verified "8/10 grade" identity, but the chains of who verified who are not that accessible. Verified achievements/activities or just CLAIMS would be so cool

I'm also still doing some pieces with Aider chat and another Gemini LLM .. cos that's two orders faster right now given not under the extreme load that Jules is.