RSS 2.0 Feed
RSS 2.0

Atom 1.0 Feed
Atom 1.0

  Death by premature generalization 


OK. I admit it. At times I do generalize prematurely. Premature generalization is a term given to the act of adding functionality or abstraction to your code simply to account for the “what if...” cases that might (or might not) arise in the future. Sometimes referred to as “over-abstraction”. Your requirements might be to code X, but you think it would be really cool to also account for the possibility of YZ so you abstract, or overly generalize your code to include for the future possible need for XYZ. You brag to your fellow programmers or to your client about how not only you can do X, but also if you ever need to do Y or Z then that is already built in. “How cool is that?!”. Well, it might be cool, but chances are that Y and Z will never be needed.

Sometimes it is hard to separate your desire to make something cool, out of your passion for programming, from sticking to the needed requirements for a task. I mean, don't you sometimes feel almost like you are doing a crappy job of something because it could be so much better?

I code because I love to code. I love writing code and I get a big sense of satisfaction out of doing something that no one else has thought of. I try to change. I try to make the time I code more profitable by strictly adhering to the defined requirements and only the defined requirements. It is hard because I want so badly to make it cooler, better, whatever. I hope to someday be able to live by extreme programming techniques that will lead me down the road to deferred generalization. Some XP'ers say that there is much satisfaction in deferring generalization. But for now I do so prematurely.

No one is happy when you prematurely generalize. If you're working fixed bid then you're screwing yourself. If you're billing hourly then rest assured that your client will not agree that the overly-generalized code is cool. All they wanted was X. How does one deal with the urge to prematurely generalize? Don't get me wrong, I don't consider premature generalization one of the anti patterns. It's not like you're necessarily creating a bad solution. Just an unneeded one. I certainly don't think that premature generalization is the root of all evil. However, even with a failing design you shouldn't be guessing at the level of needed abstraction based on it's cool factor. I guess what it comes down to is that I just want the up-front design to be cooler. Customers never want that, so what you going to do.

My name is Ryan, and I am a premature generalizer.


Leave a comment below.


  1. RoudyBob 4/30/2004 6:05 PM
    Hi Ryan...
  2. Neil 5/1/2004 6:57 AM
    Hi Ryan...
  3. Rico Mariani 10/19/2004 12:59 PM
    Hi Ryan :)
  4. you've been HAACKED 9/19/2005 2:54 PM
  5. Adelle Hartley 8/25/2008 4:00 AM
    Channel your generalization instinct into developing a library that you can sell or at least add to your portfolio.

    Premature generalization within in application is worse than premature optimization (much of what gets called premature optimization I would just call "being competent").

    Premature generalization can be defined as either
    * addressing problems that you don't have yet
    * addressing problems that you don't understand yet.

    Regarding the former, from a business perspective, time-to-market or time-to-completion matters way more than cost of development.

    Regarding the latter, it can seem worse to clients than it really is. Refactoring some naive but incorrect generalizations is often less time consuming than refactoring the un-generalized code that you could have written, but try explaining that to a client who your charging to change code they never asked you to write. And, still a net negative.

    The type of generalization that I think *does* work in almost any context, is what I call "micro-generalization".

    If you find yourself using the same 3 or 4 line pattern of code a dozen times, put it in a function!

    Not every generalization needs to be a class or a complete design-pattern informed object library.

    I think that if you stick to the basic requirements, and apply micro-generalization liberally, the effect is cumulative. Not only does it make your code more readable (if you've named your functions sanely), but you start to see larger patterns that were obscured by the large body of code that you've condensed into a few lines of function calls.

    A parable that I like to use is about a university whose builders did not lay down any foot-paths until after the rest of the university was built and fully populated with students. Then, after the students had been there for a while, they laid paths in the places where the grass had been worn away by foot traffic.

    Ok, not a perfect metaphor but I hope you get what I mean.

  6. Robertino 7/23/2009 1:35 PM
    Adelle, what you call micro-generalization is a good practise but has nothing to do with premature generalization.
    You typed:

    "If you find yourself using the same 3 or 4 line pattern of code a dozen times, put it in a function!"

    First, that is not premature (you are not guessing that you could use the same code dozen of times, you are already doing it) and, second, that is not generalization at all.
    That's just encapsulation.

Comments have been closed on this topic.



Also see my CRM Developer blog