Optimize Your Code!!!

Last December, Jeff Atwood of Coding Horror wrote that Hardware is cheap, Programmers are expensive. While I certainly agree with the spirit of his premise and eventual conclusion, it is only applicable if you are running Software as a Service. But he doesn’t say this and I wonder if it was an oversight, or if he forgets what it’s like to ship software to other people. There is clearly a case to be made for telling developers to optimize their code in shipping products.

Let’s first take a look at the rules for optimization that Jeff lays out for us.

1. Throw cheap, faster hardware at the performance problem.
2. If the application now meets your performance goals, stop.
3. Benchmark your code to identify specifically where the performance problems are.
4. Analyze and optimize the areas that you identified in the previous step.
5. If the application now meets your performance goals, stop.
6. Go to step 1.

As Jeff points out, you can multiply the performance of an application by throwing hardware at the problem. Take the guys over at Plenty of Fish who upgraded their database server to a HP ProLiant DL785 with 512 GB of RAM and 32 CPU’s. No, that is not a typo, and yes it really means 512 Gigabytes of RAM with eight CPU sockets with quad core processors. This is a classic case of throwing hardware at the problem to avoid a lot of additional engineering time restructuring and optimizing the code to ensure that the server can keep up with the workload. This was probably at least a six figure expense that saved more than a year of engineering time, so a cost-benefit analysis would show that this was well worth it.

The problem lies in the very first step where there are some major underlying assumptions which you can infer from the list.

1. This is your budget we’re talking about.
2. You have the budget and means to upgrade the hardware.
3. The software isn’t a dog out of the box.

First, if you’re running Software as a Service and your installation is the only installation in the world, then it’s easy to justify throwing hardware at the problem. It’s a lot more difficult to tell your customer that he needs to buy new hardware to get your software to run faster. Don’t get me wrong, there are cases where this approach is justifiable. Most applications slow down over time as they outgrow the hardware they are on because the business grows, but the hardware stays constant. Eventually, the system slows down until you either upgrade to a newer (and hopefully faster) version of the software, or you break down and purchase new hardware. I think most of us can agree that this is a reasonable expectation and a customer should be able to budget for this sort of thing over the life-cycle of an application.

The second problem is actually more difficult for most people to understand. It’s easy to forget that the budgets of IT departments in larger companies are far below what they used to be and these companies are completely subservient to their budgets. One person shops and small companies don’t realize this for two reasons. First, they are more profitable on a per-employee basis than a larger company. Second, they tend to look at the total dollar amounts that larger companies are making and ignore the costs associated with actually running the company. Smaller companies simply have a lot more flexibility in making purchases.

In large companies, budgets exist so people can plan ahead and make the best use of their money to move the business forward. The ultimate goal of that budgeting process is to stay in business. If you ignore your budgets, you will spend more money than you make and ultimately, that’s the reason that any company goes under. Upgrading hardware isn’t always in the budget. It might make sense, but it’s not always possible.

The final assumption is worth taking note of and is the real reason for this post, so let me give you an example. Or “the” example, rather. A few weeks ago, I was asked to perform a demo of the final Release Candidate for an Enterprise software package. Minimum requirements for the installation alone were as follows:

• Windows 2003 Server (64 bit recommended)
• 4 GB of RAM (16GB recommended)
• 2 CPU’s (4 cpu’s recommended)
• SQL Server 2005 (64 bit recommended)
• 10GB disk space

Try installing that onto a virtual environment on a moderately high end laptop to do a demo for a customer. Seriously, I’d like you to try it. Survey says! bzzzzzzzzz!

I had two main issues with these hardware requirements. First, was that they were absolute requirements to get past the installer. You couldn’t install the software unless you had 4GB of RAM and 2 CPU’s. I think it’s reasonable at the Enterprise level to require “new-ish” hardware for installing your application onto a server. The fact of the matter is that in many cases, dual socket, quad-core servers are not uncommon as a requirement to adequately run an application that touches thousands of computers in an environment. Hardware requirements like these are implemented for the “general good” of the customer.

But come on guys. If the standard mechanism for selling your software is to have a pre-sales engineer install it on a mid-range laptop to perform an on-site demo for a customer, do everyone a favor and drop the hardware requirements a bit. You can barely find a laptop that’s capable of meeting those requirements, especially if it needs to run other virtual machines at the same time. Resellers of your software shouldn’t have to bring a mini-data center to a customer site just to perform a demo. I’ve seen it done, and it’s not fun. If you’re going to enforce hardware requirements for the sake of “scalability” to keep your customers from doing something stupid, make sure that people who know what they are doing can say “I know what I’m doing, so let me do this anyway”.

That’s Rule #1.

When the hardware requirements outlined above are met and it still takes 5 minutes just to get to a login screen on a fresh installation, then something is seriously wrong. I don’t care if it’s common for the “minimum hardware requirements” to mean that it barely runs and is completely not demo-able. Dual CPU’s and 4GB of RAM in this day and age should not mean barely functional for an unloaded web application.

That’s Rule #2.

I think that ultimately Rule #1 is more important.