Well, it's food for thought, isn't it?
Operational code efficiency was not only a salient point when I was learning assembler on mainframes, but also later when I was developing/supporting analysis and reporting programs written in FORTRAN (mostly for cross-tabulation, mathematical programming and financial modelling).
The advent of the conventional 3-tier client-server model tended to somewhat obscure the relevance/need for code efficiency, but it was still relevant to mainframe operations which were being used on some kind of shared service (or time-sharing) basis - which is arguably what the current cloud-based models are.
So what @40hz
says is likely to be true:
In and of itself, it may not be that important to some developers. But to their clients, who are increasingly buying CPU cycles from cloud providers like Amazon, it's will inevitably become a major concern. ...
- i.e., it's a business issue.
For much the same reason, the TCO (Total Cost of Ownership) of an IT operation will tend to remain a business issue.@Renegade's
Or, they could hire crappier programmers for cheaper, fire the expensive ones, save $8,000 a month, and not care about the $400. ...
- would tend to be useful only in a relatively very short-term view, as, in the longer-term, it would frustrate/defeat the theoretical objective benefits of improving the processes
of software development per Humphrey's CMM, and software operation per Deming's 14-point philosophy - i.e., in the former, improvement of software development process efficiency and in the latter improvement of operational software efficiency would be synergistic business objectives.
Thus "producing the optimum cost-effective capital cost and optimum cost-effective design for fuel-efficiency for fleet vehicles" - to use @40hz's
- I thought you might find it interesting!