Premature Cleverization

“Premature optimization is the root of all evil,” say Hoare and Knuth. I have determined that I suffer from a slightly different but related malady: premature cleverization. At the start of a programming task, before I’ve written any real code, I get some wacky idea like “I could do this all with binary XORs” or “this would be cool in Lisp” or “I could write a library that would solve this and a whole bunch of other problems and make me rich and famous.” I sit up late at night, doodling diagrams that prove just how brilliant my idea is. Three days later I have a stack of diagrams and I’m ready to write some real code. I try to implement the idea. It doesn’t work. In the excitement of inspiration I glossed over — or just forgot — some flaw that makes the whole thing impossible. In effect, I wasted three days doodling and trying to be clever instead of doing real work on a boring piece of code that actually solves my problem. It’s a high-energy kind of procrastination, the sober equivalent of a drug addict’s rambling theories.

5 thoughts on “Premature Cleverization”

  1. Stephen De Gabrielle Says: Oh so familiar. What is your solution?

    Haven’t found one yet. Possibly beating myself with a stick. Or maybe just throwing away my entire supply of scrap paper.

  2. While I can’t claim to have excelled at (or even acclimated to) the idea, I picked up a great-sounding mantra from a recent software engineering class: make the simplest thing that could possibly work.

    Yes, yes… but what about the library that could generalize this solution to all sorts of other tasks? Wouldn’t that be simpler in the long run?

    No, no. It just won’t be, and exactly for the reason you described. The only way to responsibly leverage your code-hours across many different projects is to map ALL projects out to ensure that no fatal flaws exist.

    So what’s easier? If you can’t make it simple enough, then use someone else’s library. Also from that class: one sure-fire way to become a super-programmer is to reuse code. Reusing code isn’t trivial – you may still spend 3 days – but it reduces the complexity of the problem.

    Coding a library AND software to use it is attacking one problem from two sides. “Shoe-horning” an existing library into your software produces a better-defined problem, so hopefully a proper solution is forthcoming.

Comments are closed.