As a programmer, management will sometimes ask me to "think outside of the box". I saw the original puzzle, with the lines and the dots, and I appreciate that. It's not a bad metaphore.
Okay, so we're told we need to speed up the site. Years of cruft without architectural upgrade has it barely lumbering along. Like any passable programmer, I think long and hard. Do some profiling, form many hypotheses, read, look for insight, run some tests (no, parallelizing outgoing requets doesn't speed it up much at all), etc. I settle on one idea, where bytecode transforms inline method bodies to where they're called at in cases where only one implementation exists (no run-time dispatch is needed to settle which exactly subclass an object is blessed into). Three days into that, I'm put on something else. Then something else. Then I'm told to back to optimization -- I have 16 hours budgeted and I'm assigned to speed up one page, even though each page contains dozens of elements reused from other pages, and my previous approach should be abandoned in favor of operturnistic micro-optimizations. I counter-propose something with a more limited domain, where the methods with the highest execution counts are loaded with logic that walks the stack and dumps information about iterators (for loops) on the stack. I'm told not to do that either, but instead, "just make it go faster". Oh, yeah, make it go faster. Why didn't I think of that? So, now, who is thinking outside of the box? And did management really mean it when they asked for it, or did they instead mean to ask for the abscence of clever thought in favor of mindless attempts at non-workable direct routes through the puzzle?
I hereby move that management not be allowed access to the expression, "think outside the box". All in favor, say "aye".
-scott
Re:JFDI
sigzero on 2007-04-07T16:48:53
More so when it sounds like he is doomed anyway.Re:JFDI
Aristotle on 2007-04-07T16:50:40
But note In software no good deed goes unpunished.