I wrote a lot of what has been tottering on the edge of "scrap" on my own initiative in the last two years at work. The scrap in the form of unused application stubs and experimental deployment changes to modernize a legacy codebase and tests to do the same. The rest of the team is becoming interested in doing things this way. The new tests, though not formally or automatically run, have made some major changes much smoother and faster in a couple of cases for the devs and testers who were interested enough to learn and apply them.

So what could have ended as scrap is now a prescient investment. If there had been a rigid process about how I spend time at work this would have never happened and we'd still be squarely in the Perl 5.4 era with no hope of climbing out.

Thompson's rule for first-time telescope makers: "It is faster to make a four-inch mirror, then a six-inch mirror, than to make a six-inch mirror."

- Programming Pearls, Communications of the ACM, Sept. 1985

We're not just cabinet makers, we're also tool makers. What seems like a piece of scrap might end up being the only socket that will fit a bolt only hinted of at the starting blocks. I learn constantly in this work. Throwaway prototypes are often the fastest path to gaining expertise enough to not make a dog's breakfast of the actual solution. There may be scrap on the pile but the imprint of what it is, what it took, what it might be able to do remains.

This doesn't mean I disagree with what you're saying. I liked a lot of it and found some of it sincerely rallying. I think you over simplified and conflated and a lot of opposing ideas in these discussions though. Process here, in software development, is not simple.

Related: Thinking about Thinking (mappers and packers).

I know, I know, just when you thought you were out, they pull you back in.