Synthetic Monitoring

Simulate visitor interaction with your site to monitor the end user experience.

View Product Info


Simulate visitor interaction

Identify bottlenecks and speed up your website.

Learn More

Real User Monitoring

Enhance your site performance with data from actual site visitors

View Product Info


Real user insights in real time

Know how your site or web app is performing with real user insights

Learn More

Infrastructure Monitoring Powered by SolarWinds AppOptics

Instant visibility into servers, virtual hosts, and containerized environments

View Infrastructure Monitoring Info
Comprehensive set of turnkey infrastructure integrations

Including dozens of AWS and Azure services, container orchestrations like Docker and Kubernetes, and more 

Learn More

Application Performance Monitoring Powered by SolarWinds AppOptics

Comprehensive, full-stack visibility, and troubleshooting

View Application Performance Monitoring Info
Complete visibility into application issues

Pinpoint the root cause down to a poor-performing line of code

Learn More

Log Management and Analytics Powered by SolarWinds Loggly

Integrated, cost-effective, hosted, and scalable full-stack, multi-source log management

 View Log Management and Analytics Info
Collect, search, and analyze log data

Quickly jump into the relevant logs to accelerate troubleshooting

Learn More

The problem with using hardware to compensate for slow software

Are you a programmer? Want to do something for the environment and even make the world a better place? Then start optimizing your code!
It seems like today the solution to most software performance issues is to throw more hardware at the problem instead of making the software run faster on existing hardware. Doing more with less is a forgotten mantra, and Wirth’s Law continues to ring true:

Software is getting slower more rapidly than hardware becomes faster.

Jeff Atwood has an interesting article in his Coding Horror blog regarding the value of code optimization versus just buying more hardware. His argument is that since hardware is cheap compared to programmer salaries, the first step to make software run faster should always be to buy more hardware. We recommend you read the whole thing (it’s an interesting read).
He rounds off the article with this recommended approach:

  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.

This makes perfect sense if you actually go through all the steps and really do optimize after the initial short-term fix of buying more hardware.
HOWEVER, it is all too common that companies don’t take code optimization seriously enough and never go beyond step 3 above. The solution will more or less always be to throw more hardware at the problem.
In addition to this, a lot of programmers simply assume that it’s ok to demand more powerful hardware for their software to run well and don’t put much effort into doing more with the same resources.
These two things combined give us an environment where increasing amounts of increasingly powerful hardware is being used as a crutch to compensate for the poor performance of our software.

Four BIG problems

Here is why today’s tendency to simply throw more hardware at software performance problems is unhealthy and shortsighted:

  1. You do not leverage anywhere close to the full potential of your hardware.
  2. You end up with more hardware, which consumes more electricity, which will cost more in the long run (especially if you run a large-scale operation).
  3. Using more electricity is not just a cost issue, it’s bad for the environment.
  4. More hardware means more components, which in turn is bad for the environment.

Saving costs is often used as an argument for not putting in the time to make code run faster, but there are plenty of costs on top of the purchase price to take into consideration when you add more hardware; increased power consumption, sys-admin resources and future scaling issues should also be taken into account.

The implications of more efficient code

What if we could double overall code efficiency? (Don’t say it isn’t possible.) That would mean a huge reduction in the amount of hardware that companies would need to run their operations, especially on the server side (since office workers would still need a computer each).
Imagine your web servers being able to handle twice the requests they are today. Imagine modern top-of-the-line software running fine on modest, even old, hardware. It’s a nice thought, isn’t it?
Hardware manufacturers might not be all too happy with that development, though… But here is why we shouldn’t care about that:
In 2005, servers consumed as much power in the United States as televisions, and that was four years ago! We don’t know what the full carbon footprint of the world’s servers (and other hardware, it’s all running software!) actually is today, but it is bound to be significant and growing.

Why needing less powerful hardware is a Good Thing

There is another very important benefit that would come from a more efficient code base: The faster our code is overall, less powerful hardware is needed to run common applications, which in turn would make it possible to create more affordable computers. This would be a huge benefit to third-world and developing countries, not to mention less fortunate people in the industrial nations.

Please get that old-school mentality back

Huge gains in performance can be made from effective, competent optimizations of algorithms and code. Even when you think your code is fast, it can usually be made to perform several times faster with the right approach.
To give you some examples, just look at the impressive performance gains between first-generation games for game consoles and those released a couple of years into the life-cycle of that same console, or the things coders were able to make C64 and Amiga computers do back in the day. These are examples where software performance was improved by leaps and bounds without resorting to hardware upgrades.
The Coding Horror article we mentioned above has a quote from Patrick Smacchia (from, where he observes how Amiga programmers were able to increase software performance by an incredible 50 times in the time frame of just a few years by continuously challenging themselves on the same hardware.

Do more with less

If doing more with less was a more valued mindset in software development, we would all reap substantial long-term benefits. We would need less (and less powerful) hardware, we would save money, we would save power, and in doing so, we would help save the environment.
Think about that.

SolarWinds Observability now offers synthetic transaction monitoring

Powerful transaction monitoring now complements the availability and real user [...]

Exit Rate vs Bounce Rate – Which One You Should Improve and Why

Tracking your website’s exit and bounce rates will give you insight into how [...]

Introduction to Observability

These days, systems and applications evolve at a rapid pace. This makes analyzi [...]

Webpages Are Getting Larger Every Year, and Here’s Why it Matters

Last updated: February 29, 2024 Average size of a webpage matters because it [...]

A Beginner’s Guide to Using CDNs

Last updated: February 28, 2024 Websites have become larger and more complex [...]

Monitor your website’s uptime and performance

With Pingdom's website monitoring you are always the first to know when your site is in trouble, and as a result you are making the Internet faster and more reliable. Nice, huh?



Gain availability and performance insights with Pingdom – a comprehensive web application performance and digital experience monitoring tool.

Start monitoring for free