It's not.

Attempting to say it is is very akin to wanting a single, pre-created bridge to be able to span any valley. But valleys come in all shapes and sizes, and so too do the bridges required to span them.

Certainly, there are some parts that are the same. I think most of us complain about cookie cutter CRUDs or byte shuffling, but even in all that, there's generally some higher purpose business reason as to why the software is doing the byte shuffling that I am, or more deeply, why the software is doing the byte shuffling the way it is[2].

And honestly, I think that oversimplifies it, when it comes to the problem and the software that attempts to solve it. The problem can and often does change in software … so it's akin to a valley that shapeshifts, adds new local laws of physics, and requires the bridge to change and adapt. How changes to the software mesh with the existing software, and why that might be — is unique to the project. (And, as Naur argues, contained only in the heads of the developers, and what is in their heads is not even necessarily the same.)

[2] And to extend this with the shifting valley analogy, when new byte shufflings come along, would they benefit from this program's current design? If I need to extend the design, would a given extension work well? Are the requirements different enough that I need to consider something separate for this new requirement? etc.