4 ms·

If it's so little effort to add a layer of abstraction then it will be just as easy to add it later. If you end up needing to add a feature that the abstraction

by ollysb 13y ago

If it's so little effort to add a layer of abstraction then it will be just as easy to add it later. If you end up needing to add a feature that the abstraction would make easier then you can still go ahead and do it first. You won't have wasted any time, it's just that you added the abstraction after rather than before a different piece of work. If you don't end up needing it then your code is simpler and you haven't wasted any time.

angersock 13y ago
Sir or madam, the road to hell is lined with classes whose interfaces were defined after the fact. Usually you'll end up with a bunch of special snowflake classes and some classes which actually have thought-out interfaces, just enough to make you angry. Software engineering through accretion and backporting is not, by definition, engineering.
- ollysb 13y ago
  Perhaps a better way to put it is that your code base develops through assimilation rather than predicting abstractions and then shoe-horning features into them. In my experience the most elegant interfaces consistently emerge from the repeated process of adding features and refactoring the code to best fit them at that time. I can't tell you how many awkward abstractions I've had to work around at earlier points in my career because the project lead is trying to get everything to fit into their grand vision. Projects developed through assimilation mature far more smoothly because the design emerges to match reality. When you try to predict abstractions projects tend to leap and lurch. The repeated cycle is prediction, stretching, breaking and then finally rewriting.
- aaronbrethorst 13y ago
  Of course, at the other end of the spectrum, you have ridiculously over-designed systems whose class hierarchies stand as a testament to the hubris and folly of the developers who created them. I've dealt with both, and—more frighteningly—systems that veer from one extreme to the other depending on how far behind schedule the project was at the time that particular piece of the system was implemented. And then, of course, there's lots of code that lives somewhere in a happy middle.

by ollysb 13y ago

angersock 13y ago

Sir or madam, the road to hell is lined with classes whose interfaces were defined after the fact. Usually you'll end up with a bunch of special snowflake classes and some classes which actually have thought-out interfaces, just enough to make you angry. Software engineering through accretion and backporting is not, by definition, engineering.

ollysb 13y ago
Perhaps a better way to put it is that your code base develops through assimilation rather than predicting abstractions and then shoe-horning features into them. In my experience the most elegant interfaces consistently emerge from the repeated process of adding features and refactoring the code to best fit them at that time. I can't tell you how many awkward abstractions I've had to work around at earlier points in my career because the project lead is trying to get everything to fit into their grand vision. Projects developed through assimilation mature far more smoothly because the design emerges to match reality. When you try to predict abstractions projects tend to leap and lurch. The repeated cycle is prediction, stretching, breaking and then finally rewriting.
aaronbrethorst 13y ago
Of course, at the other end of the spectrum, you have ridiculously over-designed systems whose class hierarchies stand as a testament to the hubris and folly of the developers who created them. I've dealt with both, and—more frighteningly—systems that veer from one extreme to the other depending on how far behind schedule the project was at the time that particular piece of the system was implemented. And then, of course, there's lots of code that lives somewhere in a happy middle.