Van B, do you have an article that justifies future coding as well? I'm interested in reading their viewpoints on the matter.
Your argument, having cited a lack of "proper example," itself lacks example. You cited your own evaluations rather than why you came to those conclusions, for the most part.
It has generally been my experience that writing for the future, being difficult to predict in general, often results in cruft. That's not to say that having a good sense of design or the architecture you're building for, and potential change, isn't practical either.
I believe the overarching theme of that article is not to over-engineer things that don't need to be over-engineered.
KISS goes a long way toward getting stuff done. The point you made about time is good, but it's only "considering future options." We're talking about a relatively small feature here within the map editor, something that really doesn't need all of that "future engineering." If we were talking about the overall architecture of the map editor, that would be different. That's not the case, so I won't entertain that thought further.
Pragmatism is not arrogance, though. Pragmatism is,
by definition, looking at a matter in terms of practicality. If you were to say that pragmatism is something that causes the view of that matter to result in impractical application, then it is not pragmatism. Saying that pragmatism is illogical is to say that practicality is illogical. At which point it can be concluded that you clearly have different purposes than those which reward practicality. I believe what you're really arguing is over-simplifying, while the article here is, I believe, arguing over-complicating.
Is anything above a fallacy, provably incorrect, or
opinion stated as fact? (Exception: My evaluation of what the article is trying to present as the evidence is the article itself and interpretations of points made can and do vary.)
The comments section of the article seems to make a similar argument as you.
If it matters any, I should point out that both John Carmack and Aras Pranckevičius (one of the renderer developers at Unity) seem to advocate at least most of the points that article makes. (
link) Considering they're in the "game making" field, and how much they've actually done, I don't see reason to throw out the article without having first considered it. (As any deductive reasoner will tell you, be open minded.)
I should note that I'm not advocating the use for any of these methods. Ultimately it's whatever gets
you better results, in my opinion. I believe that if you always do it one way, "pragmatic," or "psychic" without any regard for the other, you'll have consistently bad results outside of controlled environments.
Don't forget that if the clients always change the specs, requirements, etc, and you
always listen to them and don't have an agreement put in place to prevent that, then you're allowing it to ruin the software you're developing, at monetary and cognitive expense. (I view this from the perspective of a lone contractor.)
----------------
Pragmatic Programming - Quick Reference
Edit: That link is posted not as an argument for nor against "future coding." However, if you take it as such, you might see a difference in approach to what is advocated in that article as "pragmatic programming," and what is advocated in that quick reference. Terms seem to get thrown around without regard to what they actually mean.
Web -
Tweets
“I'm going to punch DXGI in the face. Repeatedly.” ~Aras Pranckevicius
