Engineers love to use the highest-tech tool for their problem. It’s quite understandable as, hey, who doesn’t like playing with shiny new toys. In my experience, engineers are more predisposed to shiny things than others.
This is a problem because this goes against what the end-user wants. They just want their problem solved! They could care less whether it’s done on a shiny new Hadoop cluster, a thirty year old mainframe, or a toothpick – as long as the job gets done and gets done right every time. Meanwhile, the engineer wants to solve the problem as generically as possible so it can even solve problems that don’t yet exist.
An experience of mine some years back illustrated this point quite well. I was driving down the PA Turnpike. For those that don’t know, it’s a toll road with gates along exits so you pay only for the segments driven. As usual, I was speeding. But this time, I got pulled over by a cop. The cop took my ticket which specified where and when I entered the Turnpike, then proceeded to calculate my average speed over 100+ miles. Needless to say, my average speed was quite a bit above the speed limit, even given my visit to the rest stop. All I could say to the cop was, “I’m sorry and well played!”
Surely there were high-tech solutions for catching speeders – sensors on the highway, monitoring by air, etc. But he was able to indisputably prove that I had been speeding in a fail-safe way.
What I learned is that the crudest and most archaic tools could turn out to be the most elegant solution. It takes a deep understanding of the problem to arrive at the best solution, not one that is most flexible.
My Angel's Share 