There is a great Coding Horror write up by Jeff which gives a interesting perspective (most likely management.. but still the same) on the trade off of what your developer costs you and what new more powerful hardware costs you.

Hardware is Cheap, Programmers are Expensive

The post eludes to several key points, many of which I try to get management on numerous efforts to understand all the time.  Some hold true, but there is a point of no return.  Sometimes just throwing iron at it will only make more of mess (especially in the energy conscious era we have stepped into these recent years.)

Remember the quote, “To make money, you have to spend money.”… well the spin I see here is, “To save money, you have to spend money, sometimes.”

This directly ties into the The Programmer’s Bill of Rights.

I remember the days of Windows development that I heard that they did not want to give the development team too fast of machines, since then the code they wrote would never perform well on “normal” hardware that end users would have.  That was some what true, but much less important (excluding fancy fancy stuff) in a web centric world.  Now it has to deal with the size of the pipe and not the engine.

Over the years I have seen more times than not, is not about optimizing (as eluded to by Jeff) but cleaning and/or refactoring.  I usually find 9 out of 10 times if I refactor code when trying to make more out of it I get more bang for the buck.  But that also means you live a life of refactoring (which all good developer should).  This helps with:

• Stop the code decay / erosion.  All code dies over time.  (Try to get management to understand that one right?  Some developers don’t even understand it sadly enough.)
• Make the code more clear and concise for future developers who will have to read it.  (If it doesn’t you probably refactored wrong).
• Enhance the current functionality with less code (more bang for the buck).  Yes Virgina, there is a Santa Claus and this can happen to you too.
• Evolve the code to newer library/standards/technology.

The last bullet point is something I have found very important in the Java world.  You find that you have (or someone else) has written code for a project 5,6,10 years ago based upon JDK, lib, etc at the time.  If you evolve the code to use more modern JDK run-time libraries or even specific 3rd party libs/projects that didn’t exist back then, you can get some great windfall.  (Of course done with great scrutiny).

As always, there is not just black and white.  There is not just one solution to all problems.  Find the right shoe and make sure it fits.