Why I abstract

My boss jokes that programmers would rather build a tool to implement a feature than just implement the -- insert suitable expletive -- feature.

While this may seem like an occupational hazard, I prefer to look on it as an occupational pre-requisite. If you are not noticing the patterns in what you are doing, then the chances are you are doing the same thing over and over. And if you notice, but fail to act -- by building a tool , or a library, or a whatever to encapsulate the pattern -- you will start to get frustrated.

Here's what Richard Hamming -- see my last post -- had to say about the emotional aspect:

I was solving one problem after another after another; a fair number were successful and there were a few failures. I went home one Friday after finishing a problem, and curiously enough I wasn't happy; I was depressed. I could see life being a long sequence of one problem after another after another. After quite a while of thinking I decided, ``No, I should be in the mass production of a variable product. I should be concerned with all of next year's problems, not just the one in front of my face.'' By changing the question I still got the same kind of results or better, but I changed things and did important work. I attacked the major problem - How do I conquer machines and do all of next year's problems when I don't know what they are going to be? How do I prepare for it? How do I do this one so I'll be on top of it? How do I obey Newton's rule? He said, ``If I have seen further than others, it is because I've stood on the shoulders of giants.'' These days we stand on each other's feet!

Of course by taking the step back you learn more and do better work. Over-do it and you get analysis-by-paralysis or build a tool that does not solve the immediate problem. Under-do it and you are condemned to mediocrity. It's a Goldilocks thing.

When I have to think about a new design problem I like to explore the extreme possibilities. I know that the best one will lie somewhere in the realm of compromise, but it's exciting to explore the fringes. And often that is where the surprises and the learnings are.

The standard questions I ask -- in no particular order -- are:

1. Is this a special case / generalization of something else?
2. Is it similar to something else?
3. If I can solve this can I apply it to another issue?
4. What are the obvious approaches?
5. What are the non-obvious approaches?
6. Which is the simplest approach?
7. Which is the most elegant approach?
8. Does anyone else have any ideas about this (among my colleagues)?
9. What does the literature / web say?
10. Where does this lead?
11. How does it interact with existing features?
12. What's the underlying question / What's the real need?
13. What are the corner cases?
14. How would a functional programmer approach this?