Rules for Being a Green Software Engineer

Recently, I got a link to The Story of Stuff by Annie Leonard. This is an amazingly well done 20-minute video about how stuff is made, sold and disposed. She does a phenomenal job of putting the Story of Stuff together and selling the viewer on the importance of being Green. If you only have 20 minutes, I’d rather you watch her video than read this article, so go do that if you haven’t already.

Then I got to thinking, as software engineers, what’s our responsibility for being green? I did a couple of searches and ended up with nothing. The general view appears to be that software developers are automatically green. After all, how could software not be green? It’s just a bunch of bits, right? Software hardly has an environmental impact, or so is the consensus. Can software be any more green than it already is?

As I thought more about the subject, I realized that in fact there is a huge variance in software greenliness (new word?). The notion of green has always existed in software development under a different name: “Simple!” Yes, simple, is the word we have used to describe the most green software in our industry and some of the most successful software products of all time have been the greenest solutions. I’ll get to some examples in a minute.

But software developers don’t think in terms of developing green software. On the contrary. Because we assume all of our solutions are by default green, we end up doing things that have a huge negative environmental impact without realizing it. As software engineers we rely heavily on a few fundamentals to help us determine the best possible solution:

• Moore’s Law – By far, the most influential theory on software development for more than 4 decades has been Moore’s Law. Not truly a law of nature or science in the traditional sense, Moore’s Law was simply an observation based on the historical trend of integrated circuits approximately doubling their number of transistors every couple of years. Faster, cheaper and smaller computers being just around the corner has been the most perfect argument for writing slower, bloated and more expensive software for millions of developers over the years. I confess, I have been one of them.
• Cost of Development – As software engineers we are taught to do cost analysis in the following way:
  • – Algorithm X takes 1 month to develop and takes 1 minute to finish its calculations
  • – Algorithm Y takes 2 months to develop and takes 30 seconds to finish its calculations
  • – The resulting algorithm will be run thousands of times every day, enough to keep at least one or two servers extremely busy.
  • – Which algorithm should we choose?
  • We would do a quick cost analysis and conclude that 1 man-month of a developer’s time (in the US) costs at least 2 or 3 times more than an additional server. It would be hard to argue for choosing Algorithm Y when the up-front hard costs are 2 to 3 times as much as Algorithm X. So the slower, less green, Algorithm X wins.
• Laziness – As software engineers, we hate solving the same problem over and over again, so we build libraries of code and reuse other libraries as much as possible. This is generally great and very green! But, increasingly, we rely on 3rd party components that are thousands of times larger than the portions we actually want to use. As a result, we ship a product that requires ten times or a hundred times more disk space and memory than if the product was developed completely in-house. Of course, developing completely in-house could mean you’ll never finish the product and is not practical, but like everything else in life, there’s probably a good balance that can be maintained that makes sense for the project.

We are taught these things in school and at work. Being efficient from an economical standpoint, not a coding one, is the most important rule. Laziness and not reinventing the wheel at all costs is a trademark of a software engineer’s mentality and we can always rely on Moore’s Law to automatically solve our coding problems within a couple of years. By following the traditional wisdom, software engineers can save a little on development time, but very directly we are forcing the rapid adoption of newer, faster PCs with more memory and disk space.

We, as software engineers, are the number one marketers of hardware. We help PC manufacturers sell hundreds of millions of PCs every year just so users can run our software at a reasonable speed. That’s why when the ship-date of a product like Windows slips, stock analysts lower the estimated sales of Dell and HP. But it’s not just Windows that helps sell hardware – Windows just happens to have the most impact because it’s the world’s most popular software application. The new Windows Vista Flip 3D feature that allows you to switch between apps will probably be responsible for the sale of millions of new machines because of how painfully slow it runs on older systems. This new feature of Vista is by far the most Visible – it’s even in the Vista commercials – so it will be the first thing that any new Vista user will want to try. When they realize it doesn’t run on their machine, it’s time for an upgrade.

So as software creators, we are largely responsible for the adoption of new hardware. The smallest things that we do can make a big difference. We can’t simply wash our hands free of the environmental responsibility and put the blame on the hardware guys. Sure they want to sell more hardware, but we’re essentially their free sales force.

Rules for Writing Greener Code

I propose a set of software development guidelines for developing greener solutions:

1. Choose Faster Code over Future Hardware. Yes, if you wait 2 years and run your code on a future device, it will run twice as fast as it runs today, but that’s exactly the wrong attitude. To be a green developer, don’t use the fastest machine you can find as your acceptable performance benchmarking system. Instead, use a machine from 2 or 4 years ago with less memory, slower CPU and smaller hard drive. If it can run on that machine with acceptable performance, your contribution to the rapid replacement of hardware is significantly less.
2. Include Environmental Costs in Your Cost Analysis. You might find that writing slower code and buying more servers costs a lot less than the cost of another month of development, but don’t forget the hidden costs of more servers. These days the data center electricity alone that a server uses in a given year can cost as much or more than the server itself, not to mention rack costs, cooling costs, bandwidth costs, software costs and the environmental impact of all the materials and manufacturing processes that goes into creating the server itself.
3. Be Memory Conscious. With most developer machines having 2 or 4GB of memory these days, developers often forget that there are hundreds of millions of PCs out there with just 256MB of memory (or less!). Even 256MB is an unbelievable amount of RAM. I couldn’t imagine having that much memory on a computer at the start of this decade and now I have 2GB! It’s because developers use memory as if it was free. The argument is that memory doesn’t cost anything. You can pickup 1GB sticks for under $100! The problem is for a large number of machines that are not capable of having 1GB of memory, you need to replace the entire machine and guess what happens to the old machine?
4. Build in-house When Possible. Using 3rd party components and external controls can be a great way to save time in the development of an application, but make sure you’re not using 100MB worth of components for 1MB of gain. If the ratio of things you use in your 3rd party controls to things you don’t use is 1:100, that’s bad. It’s not just bad for the environment; it’s even bad for your end-user experience.
5. Go Back and Solve it Again. Every developer knows at least a dozen areas of their software that they could have coded more efficiently. Often the performance of re-solving critical areas can gain an order of magnitude in performance improvements. But we never go back to do it again because we’re busy adding the next new feature. Going back and solving problems we have already solved might seem like a waste of time, but it’s often very satisfying to cut down hundreds of lines of code to just a few lines and make it much much faster.

How Coding Green Translates to Shipping Great Software

So you might be asking yourself how do these rules relate to Shipping Great Software OnTime? To answer that question, let’s take a look at some of the characteristics of green software:

• Simple – The more Green a software application is, the simpler it is. So if two products can solve the same problem equally well, the greener solution will generally win. Examples include Google Search beating Alta Vista. Gmail beating Hotmail and Yahoo Mail. Flickr beating virtually all other photo sites at the time. The trend is clear.
• Fast – Greener software is going to execute faster and as a result enjoy faster adoption. Again, given the choice of two products that solve the same problem equally well, the one that executes faster will win. A great example here is the rapid and surprising adoption of FireFox. Although it still has not beat IE (a product that ships with the OS, giving it a significant marketing advantage), the adoption of FireFox has been a phenomenal and surprising success. Between IE and FireFox, clearly, FireFox is the greener tool which runs faster and consumes significantly less resources. When you ask a FF user why he or she switched, the number one reason is that FF is much faster.
• Lower Resource Usage – Greener software takes less system resources to execute. Again, given the choice of two products that solve the same problem equally well, the one that requires less resources will be preferable. Although FireFox can be used as an example again, I’m going to use the example of Apple’s OS X. As far as operating systems go, OS X is definitely greener than Windows. The latest version of Apple’s OS X Leopard runs well even on a PowerPC G4. That’s a chip that’s about 4 generations behind today’s latest CPUs. That would be the equivalent of getting Windows Vista to run on a Pentium 3. When you ask recent “switchers” from the Windows platform to OS X why they switched, a recurring theme is that OS X is faster, more reliable, it’s not as choppy and things just work. Lower resource usage is a significant advantage of OS X in this case and you sure don’t see a lot of people switching the other way to ask why they switched.

I suspect that some of you might want to ask me “then why didn’t DOS beat Windows? DOS is clearly the greener OS.” The answer is that the solution has to solve the problem “equally well.” DOS, although greener than Windows, was also single-threaded and provided an awful text-based interface. It was not intuitive to the average user and was limiting in hundreds of other ways. So DOS did not provide an equally good solution to the OS problem.

Writing greener software could be a significant competitive advantage, and as a byproduct, it could be better for the environment. It seems to me like a big win all-around.