4 ms·

Premature generalization is the root of all evil. (With apologies to Don Knuth) The original formulation may have been a real problem at the time it was made,

by paol 12y ago

Premature generalization is the root of all evil. (With apologies to Don Knuth) The original formulation may have been a real problem at the time it was made, but in our time running into ugly code due to misguided optimization seems pretty rare. Code that attempts - and almost always fails - to be generic, and instead ends up overcomplicated and awkward to use, on the other hand... It's not just 3rd party code either, in my own teams it's not rare I find myself arguing for KISS and YAGNI. Sometimes I prevail, sometimes the premature generalizers do.

arethuza 12y ago
There used to be a fashion in some parts [1] that rather than building an application to do X you would build a framework for applications of that type. Of course, the vast majority of these in-house application frameworks ended up being used for precisely one application or are overtaken by frameworks that succeed in the wider market. 1. Particularly the enterprise Java world in the bad old days.
- userbinator 12y ago
  rather than building an application to do X you would build a framework for applications of that type. ...and then someone comes up with the idea of building a framework for building frameworks to do X: http://discuss.joelonsoftware.com/default.asp?joel.3.219431.12& http://discuss.joelonsoftware.com/default.asp?joel.3.219431....
  - arethuza 12y ago
    Indeed, I managed to control myself by not posting that link as it sometimes upsets people. NB I did comment on that thread on Joel On Software.... :-)
- collyw 12y ago
  That's kind of how we were encouraged to code (I was learning during the dot.com boom, when Java was all popular). I think the difference now is that some high quality fairly generic framework have emerged (there was nothing like Rails or Django back in 2000 as far as I am aware). Why build that part when someone else has done the hard work for you? Its well tested, documented, and there is a large knowledge base out there. (I dislike it when I hear about in house frameworks when I am in a job interview, as those will generally not be as well documented, and only a few "in house rockstars" will really understand them).
thibauts 12y ago
When we add a layer of code on top of a system what we're doing is essentially locking or coupling degrees of freedom from the layer below. Trying to go the opposite way at the same time often is delusional. When I'm tempted to make something generic, it's most of times because I've built a too-focused monolithic solution to my problem. Genericity should be built bottom-up from the start by progressing up in small layers with controlled (and meaningful) interface surface reduction. Genericity is attained by composition.
Zibulon 12y ago
Or failure to generalize might hide a failure to abstract out properly.

by paol 12y ago

arethuza 12y ago

There used to be a fashion in some parts [1] that rather than building an application to do X you would build a framework for applications of that type. Of course, the vast majority of these in-house application frameworks ended up being used for precisely one application or are overtaken by frameworks that succeed in the wider market. 1. Particularly the enterprise Java world in the bad old days.

userbinator 12y ago
rather than building an application to do X you would build a framework for applications of that type. ...and then someone comes up with the idea of building a framework for building frameworks to do X: http://discuss.joelonsoftware.com/default.asp?joel.3.219431.12& http://discuss.joelonsoftware.com/default.asp?joel.3.219431....
- arethuza 12y ago
  Indeed, I managed to control myself by not posting that link as it sometimes upsets people. NB I did comment on that thread on Joel On Software.... :-)
collyw 12y ago
That's kind of how we were encouraged to code (I was learning during the dot.com boom, when Java was all popular). I think the difference now is that some high quality fairly generic framework have emerged (there was nothing like Rails or Django back in 2000 as far as I am aware). Why build that part when someone else has done the hard work for you? Its well tested, documented, and there is a large knowledge base out there. (I dislike it when I hear about in house frameworks when I am in a job interview, as those will generally not be as well documented, and only a few "in house rockstars" will really understand them).

thibauts 12y ago

When we add a layer of code on top of a system what we're doing is essentially locking or coupling degrees of freedom from the layer below. Trying to go the opposite way at the same time often is delusional. When I'm tempted to make something generic, it's most of times because I've built a too-focused monolithic solution to my problem. Genericity should be built bottom-up from the start by progressing up in small layers with controlled (and meaningful) interface surface reduction. Genericity is attained by composition.

Zibulon 12y ago

Or failure to generalize might hide a failure to abstract out properly.