The article seems to go with the premise that abstractions are most often carelessly introduced when there is an obvious alternative that is simpler and more performant.
Yes, abstractions have a cost that will accumulate as they are layered.
But simple elegant solutions are not free. They are hard to come with, so they often need large amount of dedication ahead of any coding. And as long as we don't deliver anything, we have no clue what actual requirements we miss in our assumptions.
The road to reach the nice simple solutions is more often than not to go through some some clunky ugly solutions.
So rather than to conclude with "before running to abstraction think wisely", I would rather recommend "run, and once you'll have some idea of what was the uncharted territory like, think about how to make it more practical for future walks."
But don't forget that the territory will change underneath your feet. This is especially true if you write business software. A tectonic shift in the business can make the assumptions you made a year ago completely invalid.
This is complicated further by the fact that good software will drive the business. So you will always be creating new problems because you're driving the business into new areas and capabilities that simply weren't possible before.
So this makes it doubly important to make sure your software can change in small ways over time. It's not just trying to navigate the moors at night with a torch, it's like trying to navigate the desert at night with a torch. The sand will move under your feet.
Yes, abstractions have a cost that will accumulate as they are layered.
But simple elegant solutions are not free. They are hard to come with, so they often need large amount of dedication ahead of any coding. And as long as we don't deliver anything, we have no clue what actual requirements we miss in our assumptions.
The road to reach the nice simple solutions is more often than not to go through some some clunky ugly solutions.
So rather than to conclude with "before running to abstraction think wisely", I would rather recommend "run, and once you'll have some idea of what was the uncharted territory like, think about how to make it more practical for future walks."