Is efficient code obsolete?

I was looking over some of my older code noting how inefficient some of my code was. There were a number of reasons for this. The biggest is my very short development time. In my case, the short schedules are the result of my desire to release a lot of material. I have tried to slow down my release schedule to allow for better content, but other things always seem to creep in to steal my spare time. Unrealistic schedules are far too common in the tech industry and is made worse by the fact that the vast majority of people in charge have no clue how software works or how much work is involved in its creation. Making this problem worse are the programmers themselves who often vastly under-estimate the work required to complete a project. Short development time leads to focusing on just getting the code to work not on getting the code to work as efficiently as possible.

Related to the short development time is the fact that often I will cut and paste similar code from earlier projects that I have worked on. I restrict myself to code that I have written, though there are many programmers who will cut and paste from other peoples' code.  By tweaking existing code, you can implement something very quickly. The problem is that often the code you are borrowing may have stuff in it that you are not using within the new project but that was necessary in the original project. The fact that you are cutting and pasting code probably means you are in a hurry which means that the redundant and unnecessary code that is copied will remain resulting in both code bloat and inefficient code. Changing project specifications in the middle of a project, which is sadly far to common, also results in unnecessary code bloat for similar reasons.

A third common reason for my inefficient code is that the code in question is not going to be executed very often. This is related to the first reason due to the obvious fact that functions that are infrequently used are going to be written fairly quickly. Another reason that infrequently executed code tends to be inefficient is that there is very little incentive to optimize the code as the inefficiency of rarely executed code is not going to noticeably impact the overall speed of the program. Optimising a program takes time so that effort should be placed on the parts of a program that are executed frequently or that are most critical to the speed of a program.

Not all of my reasons are related to development time. I often will write code that I can easily understand instead of using more efficient code that was harder to grok. For example:

    c = Math.min(a,b);


This code obviously sets c to be the lower of the values a or b. It is, however, making a function call which has overhead and if the function call uses floating point while the variables used are integer you have a number of type conversions as well. Many languages have generics and will inline small code blocks right into the code if compiler optimisation is enabled which can mitigate the speed difference. In the best case, the compiler would essentially convert the function call into the following statement:

    c = (a < b) ? a : b;

If you were to use the second version of the code instead of the first, you would be guaranteed no function call or type conversion overhead. I find first version much easier to understand, but depending on your compiler it could be substantially slower than the second version. The difference is in the millionth of a second, though.

None of this even gets into the facts that the code being written is often going to be interpreted or ran on a virtual machine. Likewise, the speed of computers is not looked at. Worst of all, the fact that programmers are no longer familiar with low level programming so write code that doesn't compile efficiently is not addressed. Those are topics for another column or three. Still, the conclusion that I have come up with is the simple one that computer time is far cheaper than programmer time which is cheaper than time-to-market time so it is safe to say that while writing efficient code is still something to be aimed for, getting code out quickly is sadly the bigger priority.