I’m a software performance engineer – my job is to make software faster. The ideal way to make software faster is to stop making it do things that it doesn’t need to be doing to get the job done. Any rational person would look at that sentence and say “well duh”. Any sensible software developer will look at that sentence and should be appalled that such a statement is even necessary. That said, it is. Removing busy work can take many forms such as changing an SQL query, adding a database index, reducing abstraction for specific cases, reusing reusable objects instead of creating new ones at every iteration, and using the right data model/algorithm for the job. Ideally when you get done the software is faster while using fewer CPU cycles and the originating developer has been educated as to how it should have been coded to begin with.
Using fewer CPU cycles directly relates to the new environmental movement. The fewer CPU cycles a computer is using the less heat is being generated and the less electricity is used to both power the CPU and cool the data center. In addition, the fewer CPU cycles required by a single application the more applications can reasonably share a pool of CPU resources (either on the same server, sharing via virtualized hardware such as AIX LPARs, or sharing via virtualized software such as VMWare, AIX WPARs, or Solaris Zones). The more applications you can cram on a single physical server efficiently using server’s resources the fewer servers you need, the less electricity you use, and the greener you are.
Thus my assertion is that performance engineers are green engineers. And not to make a too lofty point of it, but we play an important role of directly reducing the CO2 emissions from the IT industry, which currently accounts for 2% overall — the same as the airline industry. And if done well, the software we create just might help with reducing the other 98%.
Digital Ramblings 
Any sensible software developer will look at that sentence and should be appalled that such a statement is even necessary.
Not entirely — the best software is not the most efficient, but rather maximizes both efficiency, maintainability, and probably also time-to-market. The first goal is generally in tension with the other two.
But I know what you mean. :-)
LikeLike
I agree that the best software is a balancing act between multiple factors of which efficiency is only one.
However, I stand by my assertion that removing things from software that it doesn’t need to be doing to get the job done does not negatively impact time-to-market or maintainability. Contrarily making the software only do what it needs to get the job done should increase maintainability by having less code to maintain and increase time-to-market by requiring less code to write, test, and debug.
For example, in a recent investigation it was discovered that part of our code was doing an LDAP lookup in a loop and then not doing anything with the results. In another part we had code created to reuse a utility object only to never have the object set outside of the loop and thus created a new one every time. Both of these things decreased maintainability, required additional coding/testing which didn’t help our time-to-market, and resulted in less efficient code to boot.
I’m by no means advocating aggressive code optimizations in the general case, just stopping the code from doing stupid, unnecessary things.
LikeLike
I’m going to have to play with this a bit. If we take your case further, then we wouldn’t have software because it takes clock cycles, which are bad for the environment. Yes, I know it’s an extreme case, but the point is that we know that software is needed for reasons other than green-ness, so (to reiterate mdf356) we must balance green-ness with other values. I’m a big fan of maintainability–the computer can chug a few extra clock cycles a lot faster than I can understand too-effient-looks-greek code. I do love the removal of obviously unnecessary stuff, though. Being somewhat new to the profession, I write my share of unnecessary stuff, I know. :) But I’m getting better!
LikeLike