The cost of dead code

Once in a while I see this situation on the street. Thrash alinged around a garbage bin, somebody did an attempt to trow away his thrash but was too lazy to finish the job. 'Close but no cigar', so somebody else has got to finish the job, which in essence costs energy (and money).
In my job as a Software Architect I come across this behavior also a lot of times. Once in a while I've got to dust off an old application and investigate what the possibilities are for modernization or revitalization. Modernization ot revitalization comes down to, what can we do the extend the lifetime of an application for a couple of years more, and also be able to add agility, stability and new or changed business requirements to the application. It also helps identifying the roadmap for the future of the application. To make the roadmap for modernization there is a list of things to investigate, size of the application, the context in the application, complexity of the code, (future) business needs but also the amount of ´dead code´ in the application.
What is dead code? At one point in the history of the application functionality was removed or changed, but the actual code itself is still available in the application. For instance, a procedure which is not called anywhere in the application, a page which is removed from the menu, old functionality which is commented out, database objects that are not used anymore but still contain data etc etc. What you see here is scared or lazy behavior, scared as in 'I'm not sure if I removed or changed the right code', lazy as in 'I don't want to spend too much time'. The result is that the application is becoming like a jungle, you get lost in the dead wood. Making a change is getting more and more costly as a result of the increasing dead code. So let's change our behavior in the maintance phase, if functionality is not needed anymore just throw it away, like you would do with thrash in a garbage bin. When a proper versioning system is set up, you always can find the history back.

Reduce our IT CO2 foot print, let's green label our applications!

After reading the book cradle to cradle I started thinking what we can do in IT about reducing our C02 footprint. People start to realize that IT is consuming some 5% of our energy consumption nowadays. So all hardware companies start thinking about how to improve the energy consumption of servers. This improvement is only aimed at the run time component of the application execution.
At design time, the question can be raised, can we make our programming greener?
I started programming in the late 80's, where I've learned to program to avoid memory usage (ok that lead us into the 2000 problem...), and optimize the program to run as smooth as possible with the scarce resources in mind.
With the ever increasing speed of processors, we are spoiled and tend to program sloppy nowadays, who cares about extra loop cycles, just add an extra processor.
Actually when we look nowadays at the 'size' of an application, the term SLOC (Source Lines of Code) is used. In short, instead of measuring the effectiveness of an application, we only look at the size, so size really matters....
Let's go back to the drawing table start thinking about programming again, how can we make our applications more efficient in the usage of resources?

I think green management of an application should be part of the design and run phase, and should already be added in the offerings we bring to our clients. Cars have an energy level, so why don't we green label our applications?