That’s part of the problem. Usually the output and behavior of a program is well specified enough that we should have a checkbox (test?) for it. This is more about the process of development than the artifacts.
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.
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.
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.
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
(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)
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. :)
Thanks, I needed a good laugh ;-)
But that also makes it somewhat intangible and the ability to analyze, test and observe a large software construct relies on the mental capacity to read and grasp units of code and its complex interactions. Once components start messaging with each other and cross-influence their state you quickly enter the realm of complexity theory and tight control of information flow is the only way to guarantee some degree of predictable outcomes.
When I see these ship assembly videos, it's very tough engineering and often novel territory but you got something in your hands, you see the parts move and can measure their forces and evaluate interactions. Every nut has a checkbox, but code lines don't.