[com2kid]

I have known developers who, given a moderately complex programming task, will complete it within a reasonable amount of time. The code will be correct with no more than the expected bugs, and the design will be OK as a stand alone piece of code.

The design will not be ingenious. It will not take other parts of the system into account. It will not have simple tweaks done in preparation of future design change requests, tweaks that would make the code no more complicated, but many times more flexible. The code will not be as eloquent or as simple as it could be. A slight alteration to the initial design would have greatly simplified the code and ensured against bugs.

Then there is the opposite side of things.

The programmer who understands the greater business needs of the product, and writes code in anticipation of what is to come. Not entirely abstract to the point of ridiculousness, but with proper hooks put in that will be needed later. A software engineer who thinks past the most obvious implementation to what sorts of implications different designs offer. A software engineer who creates eloquent and understandable systems.

Yes one can argue that proper procedure and design reviews can enable the OK developer to reach the level of the Software Engineer, but at what cost to overhead? 2x? 3x? How many meetings, how many discussions?

There is a huge productivity difference between even experienced developers. Denying that is purposeful blindness.

[chris_mahan]

YAGNI is a virtue. Make to code loosely coupled so the system can be modified in-place when the time come rather than building features that may not be needed in the future.

[silverbax88]

This is a valid thought, but I would piggyback on your comments and add that there are also engineers who put so much thought into their code - usually with the goal of eventual design expansion or reuse - that their code becomes over-engineered to the point that it, too, causes loss of overhead.

[chii]

There could be two explanations - one is that the engineer who "foresaw" the future requirement just got lucky. The other possible explanation is that they really had a black art in deciding what's needed, and what's not. And black art takes time, and experience, as well as some level of intuition (some might say its heuristic - but heuristic is just shortcuts for lots of gathered experience).

[com2kid]

Bingo.

I have done a good deal of studying of UX, I come from a background in testing, and I am now a developer.

Systems I design take all three disciplines into account. A junior UX team asks for something wonky in V1 of their spec, I code it to spec, and then make allowances for what V2 is likely to actually do. Typically a few extra fields in a struct, or designing a state machine to be a bit more flexible than strictly necessary. Maybe I break some logic out of the main class into a secondary independent one that can be passed around.