How much energy is needed to write an e-mail?


In 2013 we sent 182.9B emails, consuming 26PJ (Peta Joules). Equivalent of yearly electricity consumed in Mongolia and 1kg of matter-energy.

Every time an e-mail is written, or any sort of human-computer interaction, some amount of energy is expended. Given that in 2013 an estimate of 182.9 billion e-mails written world wide an interesting question pops up:

How much energy is needed to write an e-mail?

By energy I mean how many Joules and by needed I mean needed by the human who writes the e-mail and the computer used to write the respective e-mail. For our calculations we’ll take an e-mail length of a 100 words. I don’t know the average e-mail size, but perhaps I should ask NSA, FSB or MSS some time to get a more accurate idea.

Sending an e-mail involves e-mail servers, routers, switches and other network devices which require energy in order to function, but given that the topology of the internet is rather hard to take into account, we’ll not bother with these details. However I suspect that the infrastructure itself that is required to send a single e-mail consumes far more energy that opening up your computer and sending the e-mail.

At this moment I’m not sure if it’s even possible to calculate this accurately, but let’s try anyway and please if you find any mistakes feel free to point them out.


zope.component introduction

Recently I gave a talk about zope component architecture at a company in Paris where I started consulting on zope, plone, django and python in general. In these posts, aided by code examples, I will try to show what zope components are capable of, what are the common use-cases and some of my personal views about the subject.

First lets identify the problem that we are trying to solve using a component architecture:

Applications tend to get big. Especially those applications that have a lot of users and have years of development. Users want different features/changes in different stages of the development of the product. Hence the key to a successful and long lasting application is to comply with the user needs as fast as possible with as little technical dept as possible. Finding a balance between the two is not easy.

Speed of development is important especially in the beginning of a project. Your clients want that software today and you can’t waste time on thinking a lot about long term benefits if your bank account is empty. Those benefits are nonexistent if you don’t finish in time so the shortest path usually gives you the best chances of success. This is the correct way to think about it. However when the project is getting bigger you may want to start thinking in different terms. Questions like these are usually good ones to ask:

  • How much time does it take to create a feature?
  • Refactoring is hard, but can it be made faster?
  • Is it easy to extend existing features?
  • How different parts of your application talk to each other?
  • How about debugging?

These questions matter both to managers and coders. Even if the managers and developer are very good at what they do usually what happens is that layer after layer gets added on top of the existing product until it becomes a big pile of crap – new developers are screwed because they can’t figure out what is happening in the system and the time to train them is very expensive. New features take enormous amounts of time to develop and your technical dept gets bigger and bigger with every new modification.

Very little can be done about this once you’re big. There are no easy solutions and old applications sometimes just whither and die. Tough. But maybe components can help.