I've often taken a different view on this liminal space point, which I use to demonstrate how bad the current state of software is. Most software isn't able to ignore gravity in this sense, but must instead abide by a flawed version of gravity designed by an intelligent idiot, that is someone too stupid to do something correctly and yet smart enough to cause a lot of damage with his limited abilities. It would be as if a house had gravity making a sink impossible, but of course people want sinks, and so an overcomplicated sink that can't work correctly in all cases must be installed. This shows that getting the constraints right early on is not only proper, but required.
To avoid the soft constraints of bad systems, I often find myself retreating to the universe of a language which defines enough for me to work. As an example, Ada has what are called tasks, which are independent units of program execution, and by using Ada I can have a program which may or may not be structured according to the underlying nonsense, but I needn't worry about it so long as it can't affect me. With the Ada compiler I use, tasks are implemented as processes, or whatever, but I only care that I can have them perform certain blocking operations with the UDP library I've designed, and beyond that care not at all.
This circular specification problem I don't wholly accept. In many cases, software can be split into units called libraries which are fully understood ahead of time. It makes sense to turn any vague program into as many libraries as possible, and to otherwise reduce its size as much as one is able. If the vague program is small, it can be written, changed, and discarded very easily. Another method is to use an interactive language like Lisp or Smalltalk which allows one to push as many decisions as feasible to the future. I find it telling that this was never mentioned in the article. These so-called blueprints are commonly known as metaprograms.
Language choice also affects the observer effect in the same way. I use GNU Emacs, which is very easy to modify as it runs. One way to deal with this so-called effect is to make software easier to modify within itself, or at least distribute it as source code which can be changed very easily. Neither of these alternations are mentioned in the article, however.
I feel our viewpoints are too different to have much of a common language, it seems.
Regarding specification, while I agree that the source code is the spec, too many projects also do not document in an abridged form their architecture or how the software is to be used or amended. That is a big mistake, as it makes it very difficult for others to then use or amend it.
There are two fundamental differences of software that you left out, one perhaps because it's obvious but it is so important that it is worth emphasizing. That is that unlike any product before, almost all the cost is in the upfront design, because you can then copy and distribute the software for almost nothing. Economists would say the fixed cost is essentially the total cost of software, since the marginal cost is negligible. This was true of no product before, though software also makes it true for digital media now, and puts tremendous pressure on the functional design of software, raising the importance of your triad of software design issues.
The other is that all information systems are a combination of logic (if-then-else clauses) and algorithms (do-while-for loops). The computer, by automating and vastly speeding up both, has radically transformed what information systems are capable of.
We can now create vast forests of logic, and speed up algorithms to levels unheard of before the computer. Consider the Dewey Decimal classification system that most libraries used before the computer, where it was known that manual search and retrieval was slow, so a tremendous amount of upfront time was spent on the logic of classification, to help speed up the slow lookup algorithm. Today, we can just slap all the information online uncategorized, and let computer search engines build search indices for us. Another example is that I no longer have to bother putting all my local digital files in different folders to help me find them later, because full-text search algorithms now run so fast to find anything I need on my computer.
I think we are still struggling with the implications of the computer radically changing what breadth and kind of logic and algorithms are now possible, by automating them to speeds unthinkable before.