Sunday, October 14, 2007

Software Development and the Environment

What can software leaders do to help improve the environment? Reduce the footprint we leave in the process of doing our work. Each of you may have unique ways you can do this, but there are some that could be nearly universal and I'll cover those here. The areas I've actually been involved with are listed below, followed by more details about each in terms of what to expect and the challenges you are likely to have. Each of these specifically reduces consumption of energy, and in the process, lowers production of GHGs (Green House Gases) and a collection of nasty, poisonous compounds including VOCs, CO, SO2, and NOX.

  1. Work remotely.
  2. Encourage alternative transit.
  3. Turn off the servers.
  4. Run virtual machines instead of deploying more servers.

Work Remotely: reduce trips to and from the office. To do this, your organization will probably require the development of new skills for you and your department. Don't bet on videoconferencing - it's not the same. Make sure your entire team has quality headsets so you can conference call and everyone can hear and be heard. Don't try to mix remote meetings and in person meetings - you want equality in the handicap - otherwise the local meeting takes precedence and you'll lose the remote attendees because they can't hear as well and don't have the benefit of the non verbal in person communication. Get a good conference calling service that has mute capability both for the organizer and for individual lines. Your team will probably need to prepare better for meetings - which is a side benefit. They'll need to prepare and distribute relevant material in advance. You will benefit by acquiring a remote collaboration tool; I haven't found one that is perfect yet, suggestions solicited. If you are going to try to draw, get a tablet.

Encourage Alternative transit: increase efficiency of per passenger commute. Don't get me wrong, I'm not saying this works for everyone, but when it makes sense, promote it -- people won't generally think of it on their own. Most places I've worked implicitly discourage anything but driving - they would rather know the person can stay the extra 15 minutes when necessary rather than catch the shuttle/train/bus. This is really counterproductive, because what it is doing is causing more people to use a system that has horrible scaling properties, so you end up wasting your employee's private time - thinking that this doesn't come out of your time is naive. The federal government has a program that enables you to get a tax benefit for sponsoring your employee's use of public transit or vanpools. It's a tax free bonus to the employees, and a tax benefit to you. Think about alternative transit when you lease that new building (I interviewed once with a company who was located one block from a METRO station near LAX, and the leaders didn't even know that). Make it easy for employees to get to and from the transit location.

Turn off the servers: lower electricity use. Those servers at 200W or more each, really add up. I've worked in environments where each developer's office has a row of servers on the floor, and for the most part they are powered up. Assume an average of 3 such servers per developer, and that is
3 x 250 x 24 x 365.25 = 6,500 KWH
per developer per year. If you have 100 developers, that's 600MWH. At 1,100 pounds of CO2 per MWH, this is 330 tons of CO2 annually. Staggering. Turn them off. This should be easy to make happen.

Use virtualized servers: lower electricity use. This will be easy to sell to your CFO, your safety officer, and the IT department. Those many configurations of developer test machines you need - convince your developers that they need to help the environment and your IT and energy budget by virtualizing (e.g. VMware or Parallells). You'll can probably sell this by telling your developers that this way they can always have the highest performing servers instead of the old and dusty ones that are often relegated to test. By hosting multiple configurations in one machine, you don't have the capital risk nor the energy consumption of a large number of test machines. The challenge will be that developers often don't want to deal with the extra layer of software; maybe IT will provide some help to do installs for the developers in exchange for the lower maintenance provided with fewer machines.

No comments: