Who cares about inefficient code

At the risk of stirring up a hornets nest, I'm getting really tired of the naysayers who quickly play the "it's not as efficient as hand-crafted code" card when a new, high-level programming or design technique comes along. They just don't seem to get it that the question of 'efficiency' extends well beyond the run time of the application. In the real world of commercial pressures, making successful products is not just about the performance of the end product. It's also about your ability to develop, deploy and maintain that product within the window of opportunity given to you by the market.

This little rant of mine was provoked again after I read a recent FPGA Journal article 'Drag and Drop vs HDL?' by Dick Selwood. It was a well-written and informative article about National Instrument's continued push into FPGA design with their drag and drop design environment. But all three reader comments (as of today) focus around the efficiency of the code produced by GUI based design approaches. Now come on guys. Surely you can try a bit harder. Of course hand crafted code is going to be more efficient than GUI-based stuff. But that only matters when it matters! To write off the whole GUI-based approach on account of the few situations when it isn't suitable is way to short-sighted. And it's not like NI is taking away the ability to use hand-crafted code. They are simply giving you the choice.

The real problem with the "it's not as efficient as hand crafted code" argument is that although it sounds rational, it places us in a very dangerous position of being dismissive of the whole technique without giving further thought to whether that technique will be disruptive. If you ever get the chance to read "The Innovator's Dilemma" by Clayton M. Christensen then I highly recommend you do. It gives some really strong reasons why it can be suicidal to ignore new technologies on the basis of how well they fit current market demands. Technology doesn't stand still. It continues to push on at a break neck pace. If we dismiss a technology today because it appears to be inefficient compared with established techniques, we run the risk of being blind-sided when technological advances suddenly make the inefficiencies irrelevant. By that time, it is too late to reposition ourselves around the new way of doing things. As the book puts it, the real question is not about efficiency, it is about how disruptive the 'new thing' will be.

So here are my rules:

1) If something looks slow, technology will make it fast.

2) If a new design technique raises the abstraction level, gets you to market faster, or allows broader access to growth technologies (i.e. disruptive), it will supplant other techniques.

3) There will always be a need for hand-crafted solutions. But the proportion of products that must be hand-crafted will decrease.