ABA: Always Be Abstracting
From Don Gray's post today about "single point requirements":
The take home lesson we learned, "Don't accept a single example for requirements that cover a class."
Don's story reminded me of a saying I like that is based on something said by Alec Baldwin's evil sales manager character Blake in the great David Mamet movie Glengarry Glen Ross (which is also a play). During a tirade disguised as a pep talk to a slumping sales staff, Baldwin's Blake writes on a chalk board in big letters, A B C, and then yells, "Always Be Closing!"
My own variation on this advice: Always Be Abstracting--though I won't yell it out or try to humiliate anyone as Blake does. We must abstract, because our clients usually don't know how, and don't know how important it is. Abstraction always has a cost, though, and there's a point at which it becomes irresponsible to keep abstracting without an explicit indication from the person paying the bills that the abstraction is warranted.
There's a great term that I first encountered in Martin Fowler's book Refactoring: speculative generality (I often use the variation speculative generatization, but I think "generality" was the original coinage). It's so tempting to say "The software may need to do this someday" and go to work building a super extensible, infinitely morphable kitchen sink program. I point this out to acknowledge the humorous exaggeration in my use of the word "always." Always never means always.
Dan
Glengarry Glen Ross
What's fun is when management tries to "motivate" programmers with a talk like that given in David Mamet's play.
Some clown who usually gives sales motivations is called in to "save" late project by calling the assembled programmers "faggots" for not meeting deadlines. I saw this happen in Chicago.
It might not be thought to happen at "enlightened" companies, but the trouble with "enlightened" companies as I saw it in Silicon Valley was that the attracted damaged souls who abused all the enlightenment to slack off, steal equipment, and work on their own businesses on company time, with the result in a Dialectic of Enlightenment that the company would crack down, principally on the developers who'd behaved themselves.
I do think that people who say that "business is all about people" need to read David Mamet and realize that one reason why programmers may prefer machines is that REAL people in the REAL world can be such stinkers.
But I do agree. Always be abstracting.