> Usually the output and behavior of a program is well specified enough that we should have a checkbox (test?) for it

I've literally never worked in a project like this. It's always "here's some general idea of what we want, with a couple of hard constraints. Build it however it makes sense to you, and we'll change anything we don't like after we see it." The only exception I can think of is data import from a known file format or API.

It's very easy to explain to someone why blowing a hole in their bedroom wall to put an extension cord through it is a bad idea. On the other hand, try explaining to your product team that building a certain feature in 2 weeks will require doing the equivalent of that, and they won't see any issues with it.

This is the problem with building software. It's intangible and non-developers have a very hard time understanding the tradeoff of doing something "hacky" vs doing it right.

> Usually the output and behavior of a program is well specified enough that we should have a checkbox (test?) for it.

lolnope

Or at least, if there is such a specification, it's never in a single organized form but scattered around the tickets, emails, postit notes and memories of the team members. And filled with assumptions on what's expected.

Only the most complicated, expensive and safety-critical systems get that kind of treatment. At which point people start realising that the requirements engineering is actually one of the most difficult parts for business applications. Some projects have collapsed with millions spent before writing any code, simply trying to untangle the requirements.

> ...requirements engineering is actually one of the most difficult parts for business applications. Some projects have collapsed with millions spent before writing any code, simply trying to untangle the requirements.

This gives me a terrible idea:

Put https://xkcd.com/1737/ (Scale) and continuous integration into a blender.

Stand up a whole new team to build out your Ultimate Last Widget, from first principles, every 5 years. Have maybe 5 teams running continuously.

Each team operates asynchronously from all the others and there is no blocking.

Maybe teams can freely exchange ideas, and maybe workers can switch teams at will.

Hmm. This would unfortunately result in a Super-Team™ that knows how to create a new Widget X from scratch in (eventually) record time, but not necessarily maintain it.

And there's the good question of whether squishy real-world influences would cause the last of the teams to succumb to second-system effect...

Wow this is hard

Some defence projects end up being run like that. Although it tends to operate in reverse: project A has been running to produce the Ultimate Fighter for 20 years, but that's taken too long, so a slightly scaled back project for Acceptable Fighter is launched. Ten years later, neither is finished, so project Desperate Stopgap fighter is launched. Another few years on and an actual war breaks out, so Obsolete Fighter With Guns Taped To It is used to do the actual fighting until the losses are unacceptable and all the preceding teams are galvanised into producing actual results.

(e.g. https://en.wikipedia.org/wiki/The_Pentagon_Wars , but also applied to a lot of early WW2 and things like the UK V-bombers)

The V bombers were more a case of missiles? Oh, we never thought of those, let's make an inspiring Pathe newsreel and pretend they are still cutting edge.

Though your tale is a pretty close summary of the political story underneath cancelling Supersonic Harrier and TSR2 for F111, and the Buccaneers and Phantoms we eventually ended up with. Though you missed the opportunity beloved of politicians to merge Acceptable Fighter with Acceptable Naval Fighter into one aircraft and end up with White Elephant that barely flies, and certainly doesn't float. :)

> and behavior of a program is well specified enough that we should have a checkbox (test?) for it.

Thanks, I needed a good laugh ;-)