Reading Leviticus today.  Chapter 19.  “⁹ When you reap the harvest of your land, do not reap to the very edges of your field or gather the gleanings of your harvest. ¹⁰ Do not go over your vineyard a second time or pick up the grapes that have fallen.”

A rather interesting instruction.  Why are we not to be as efficient as possible?  Yes, in that immediate passage there is a reason given: charity.  “Leave them for the poor and the foreigner.”  But there are other, similar injunctions against efficiency, and even technology.  (Have a search for passages about cisterns, etc.)

Our society, of course, makes a god (and idol?) of efficiency.  We see whole businesses built on being just that much more efficient than somebody else.  That seems to be the whole idea behind outsourcing, for example.  But another example is Enron.  Businesspeople seem to think they can shave the margins just a little bit more, and make fortunes in the process.  There are lots of examples in the financial world, most of them bad.  Stock markets, and crashes.  Derivative instruments, and bank failures.

Now, we like efficiency in the technical realm.  In fact, we assume (as an unexamined article of faith, if you will) that we are making everybody more efficient.  (This is why Microsoft is currently trying to promote the use of Windows 7 on smartphones with a series of ads showing people being frustrated and sometimes fatally distracted by their smartphones.)  (No, I don’t understand it, either.)  I could, I suppose, go on with a series of examples of how social networking is making people waste much more time than ever before.

But that’s not my point.  The point I’m working towards is that we, in technology, are actually very wasteful.  We get newer and more powerful machines, and then put more bloated and inefficient programs on them.  (On a laptop, I once found that, simply by switching from the newest level of graphical user interface to an older, less colourful, but still perfectly usable interface, I could double the battery life.)

Going deeper than than, nobody does code optimization anymore (other than turning on the optimization switch on the compiler).  We are running larger, and slower, programs.  Partly because we are running larger programs, and nobody wants to spend the time doing optimization on that volume of code.

But optimization can be a very bad thing, too.  Larry Wall, who has quite a gift for the apt observation, notes that “[o]ptimizations always bust things, because all optimizations are, in the long haul, a form of cheating, and cheaters eventually get caught.”  You want a second opinion?  How about William A. Wulf: “More computing sins are committed in the name of efficiency than for any other single reason–including blind stupidity.”

Going back to the example of code optimization, if you do it, your source code no longer truly represents the executable code.  And, whatever you did to shave ten cycles off the operation, or a hundred bytes off the file size, it’s going to be more complex for someone to figure out (and very possibly leaves a hole that someone can exploit).

In the malware field, back in the simple old days when we only had to worry about boot sector infectors and file infectors, most file infectors would attach themselves to the beginning or end of the infected program.  So, if you were a virus scanner vendor, and you wanted to win the speed race, you would only check the beginning and the end: top and tail scanning.  Trouble is, while most file infectors attacked there, that wasn’t the only place viruses could get in.  So, optimizing for speed, you sacrificed protection and accuracy.

Are we doing the same things in other areas of security?  Yes, we always have to do our cost/benefit analysis, and try to make sure that we are giving the best protection for the resources available.  But are we, for example, pursuing certain “metrics,” and forgetting some aspects of the larger picture?