Interesting POV, to which I partially disagree.
I was recently working with a mathematician gone developer, and his skills in organizing code into separate layers and reusable components were quite poor.
A single data point, but I think this capability comes largely from experience, not from a mathematical mindset.
After encouraging the whole dev team to document more their code, insisting on the "why-not-how" and spend-time-properly-naming-stuff parts, I was still quite dissatisfied, but gained some insight when I found out that when even they had to explain the algorithms as they were thinking them, it was still a big mess. Corner-cases not explored, using name A for something which is actually a B, etc...
The capability to see bugs before they happen is imho a thing of experience.
You probably remember the day you realized that storing all dates as timestamps in UTC is the only sensible way, and that storing them in localized-timezone format or truncated-date-such-as-a-day is calling for trouble. Or when it dawned on you that assigning different meaning to the NULL, FALSE and 0 values of a variable was not a good idea. Etc... (just a couple of random examples of things which are good coding practice but hard to teach and check with automated tools).
But, more importantly, the capability to see business requirements changes before they arrive is really the holy graal, much more than the propension for good architecture. And again, that takes experience, it is not hard science.
If you are the genius-technical-program-leader, all my respect.
But more often than not overspecification does not lead to better projects. That it does not work is proven: otherwise we would all be doing waterfall in 2014.
The problem with specifications is that they always lie, because the end user is not an engineer
. his ideas are vague and contradicting
. he has no clue if a small change he asks for has a huge impact on development or not
. he can not even see the better ways to do things he asks for which are in fact possible
Also the developer is bound to the spec, not to the user needs, so
. he can not question the need for any feature or propose changes
. he has no vision of the big picture
. he ends up coding something that will clearly be thrown away in the next day
In most projects, the more you give importance to the spec, the more you end up putting diving walls, and reducing communication. Between end user and programmer you now have business-requirements-analysts, project manager, scrum master, maybe more. It ends up a bit like when you were young and played cord-telephone.
True, the more pressure you put on churning out features upfront, the more tech debt you incur, and the bigger the need for refactoring later. But pressure is not the only thing.
Communication is the key, and the more your project makes it flow, the better.