I think you're still fundamentally understanding what makes a specification different from "code". A specification is to a program as a building plan is to a h

I think you're still fundamentally understanding what makes a specification different from "code". A specification is to a program as a building plan is to a house. I spend less effort on drawing the plan that I do into the house, although I wouldn't put anything into the plan that I don't want to end up in the house that will (eventually) be built. Similarly, once the house is built, I can verify (presumably using a tape measure) that my house implements my building plans. But I can't live inside a blueprint. So, while this is not a formal definition, I think a good (informal) means of distinguishing a specification from a program is that if the specification could be substituted for the program it is specifying, then it's probably not a specification in any useful sense. This is to negate the usual argument that "my poorly-hacked C code is the specification for my program". The "push a button" argument is a bit of a red herring. "Pushing a button" is a convenient metaphor for "perform some low-effort, largely-mechanised process". If your complaint is that it's an over-simplification, perhaps it is worth thinking about what the intention of the article was. It's not a work of serious theoretical value - it's simply advocating an ideological position to an audience of programmers who don't already know about specification and think that it's a good idea.