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.

Page 1 of 3 | Next page