Engineers have certain counter-productive tendencies. I can say this since I am one. :-)
Engineers like to think... and they sometimes do things simply to allow themselves the self-interested conceit of thinking more than necessary just because it makes them feel good ("Yeay, I get to exercise my brain!"). If they just followed two simple principles, they could spend so much less time complicating everyone's lives:
1) Deliver working software.
2) Build what you need when you need it.
Of course, these are two of the fundamental concepts behind Agile. Unfortunately, some engineers obsess over the principle of good design -- or at least what they believe is good design -- and they practice the kinds of things you address in your article. But customers don't care about how good your code makes you feel. The unfortunate reality is that some engineers are more worried about writing code that makes them feel good than they are about writing code that delivers direct value to customers.
And this leads to your point about balance. Yes, it's subjective, but when you can't point to the direct, immediate value added by your abstraction (or whatever extra code you're writing), you've already gone further than necessary. You're wasting time with unnecessary code, and you're probably wasting other engineers' time by increasing their cognitive load since they have to think more about what your unnecessary code is doing and why it's there ("Ok, now I understand it, but what purpose does it serve?"). Wasted time means slower-than-necessary product releases. The reason we shouldn't write code for something before it's actually necessary is that we know it might never be necessary, and if it turns out it wasn't necessary, you slowed down a release for no reason... and possibly lost to the competition.
We embrace change, and part of embracing change is doing what you need when you need it, not before you need it, because you know the requirements will change again... and again... and again...
For further actions, you may consider blocking this person and/or reporting abuse
We're a place where coders share, stay up-to-date and grow their careers.
Engineers have certain counter-productive tendencies. I can say this since I am one. :-)
Engineers like to think... and they sometimes do things simply to allow themselves the self-interested conceit of thinking more than necessary just because it makes them feel good ("Yeay, I get to exercise my brain!"). If they just followed two simple principles, they could spend so much less time complicating everyone's lives:
1) Deliver working software.
2) Build what you need when you need it.
Of course, these are two of the fundamental concepts behind Agile. Unfortunately, some engineers obsess over the principle of good design -- or at least what they believe is good design -- and they practice the kinds of things you address in your article. But customers don't care about how good your code makes you feel. The unfortunate reality is that some engineers are more worried about writing code that makes them feel good than they are about writing code that delivers direct value to customers.
And this leads to your point about balance. Yes, it's subjective, but when you can't point to the direct, immediate value added by your abstraction (or whatever extra code you're writing), you've already gone further than necessary. You're wasting time with unnecessary code, and you're probably wasting other engineers' time by increasing their cognitive load since they have to think more about what your unnecessary code is doing and why it's there ("Ok, now I understand it, but what purpose does it serve?"). Wasted time means slower-than-necessary product releases. The reason we shouldn't write code for something before it's actually necessary is that we know it might never be necessary, and if it turns out it wasn't necessary, you slowed down a release for no reason... and possibly lost to the competition.
We embrace change, and part of embracing change is doing what you need when you need it, not before you need it, because you know the requirements will change again... and again... and again...