Monthly Archives: December 2007

Why should I buy carbon credits?

I have noticed a slew of websites appearing on the net that sell carbon credits to people that want to offset the carbon emissions produced as a by-product of the goods and services they consume. Thanks to former Vice President Al Gore’s eco-documentary An Inconvenient Truth — and I say this with tongue in cheek — we are now all aware of the climate change effects of carbon dioxide emissions. Maybe it is this new awareness (or guilt) that encourages us to open our wallets and purchase these carbon credits.

Buy for hundreds of thousands of download music from your favorite artists at everyday low prices. download music, classical music, new releases. download full version movies, updated daily DVD Movies Download Movies, Download Latest top horror movies enjoy dvd movies.

But what do you really get for your carbon credits? Web sites like greenpig, Climate Friendly, and Carbonfund charge about $25 to offset 1 tonne of carbon emissions, and you get a nice little certificate to certify your purchased carbon credits. You can then hang that certificate on the wall and feel good about yourself.

It is worth noting that you can purchase 1 tonne of thermal coal for about $70. Roughly 1 tonne of coal produces about 2 tonnes of CO2 emissions. So if you bought half a tonne of coal for $35 and stashed it somewhere so that it is never used, then you are effectively sparing the Earth of 1 tonne of CO2 emissions for the cost of $35. So maybe these carbon credits are cheap by comparison. It will certainly save me from stockpiling coal in my backyard.

So where does your money go? Well they go to environmental projects such as tree planting and wind farms. As to how much of your money goes directly into these projects is another question. I am highly sceptical of these carbon credit businesses (if you can call them a business). They are probably more like charities where about 15% of your donation actually goes directly to helping people in need, and the rest of your money is wasted on expensive overheads like the CEO’s salary.

Buying half a tonne of coal and stashing it in your backyard is sounding like a more effective strategy. If everyone did this then coal prices will increase due to a reduction in supply of coal on the open market. Energy becomes more expensive as a result, and economists would lead us to believe that consumers will demand less energy as a result. Consuming less energy will mean less CO2 emissions.

Also why would I want to give my hard earned money to these businesses so that they can then invest in wind farms that will eventually make them more money? Where is my cut of the money from these wind farms? You would be better off investing your money directly into a renewable energy company that is listed on the stock exchange. At least then you become a shareholder in the wind farm and can earn dividends and capital growth from your investment, and still feel good about yourself for saving the planet.

The only benefit I can see from purchasing carbon credits as an individual is that I will effectively be giving up a proportion of my income. By giving up a proportion of my income I will therefore have less money to consume carbon dioxide producing goods and services. Although at the same time I will probably be making somebody else rich, presumably the owners of the carbon credit websites, and thus enabling them to purchase more carbon dioxide producing goods and services than me. So at the end of the day this notion of carbon credits will simply redistribute carbon emissions amongst society with a bias towards the rich.

I will never opt to buy carbon credits as there is no clear way of measuring the effectiveness of the individual’s contribution. I will however endeavour to become more eco-friendly by continuing to buy energy saving light bulbs, powering down my workstation at the office over weekends, and petitioning Google to change the background colour of their search page to black.

Christmas Party

I just got back from my company’s Christmas party in Melbourne. Yes, that’s right in Melbourne!. I was one of four that won a trip to the ThoughtWorks Melbourne office Christmas party, all expenses paid. The prize included hired car to and from the airport and one night’s accommodation in a serviced apartment. ThoughtWorks were even generous enough to pay for partners to go as well. A similar prize was offered to the Melbourne folks to attend the Sydney Christmas party held in November.

I have to thank Kai, a colleague and new hire for drawing my name from the office raffle. Kai worked with John and myself on a project before rolling off on Friday. Funnily enough Kai thought that he had seen the last of John and myself after 6 weeks of friendly “hazing”, but had unwittingly invited us to his office Christmas party. Anyway it was a good opportunity to get the team together for a photo (below) before we all move on to different projects next year.

Me, Kai, and John

The party kicked off at 7pm, but most of us arrived a little earlier at One Fitzroy in St Kilda. The entrance had red carpet laid out, a professional photographer (aka the Paparazzi), and a person interviewing all attendees. Our managing director gave some sound advice for the evening when interviewed, “pace yourself throughout the night and finish off with a bang”. It was very Hollywood, and everyone was dressed to impress. The night kicked off with beers and champagne, followed by an open bar, hors’ dourves, prizes, dancing, and lots more drinking into the early hours of the morning. ThoughtWorks certainly do know how to throw a party!

Frequent upgrades will minimise your project’s tech debt – a Spring 2.5 upgrade experience

On my current project we upgraded from Spring 2.0 to Spring 2.5. The upgrade was almost as simple as dropping in the new Spring jar. As of Spring 2.5 the web MVC component has been split out into its own module, so now you need to include spring.jar and spring-webmvc.jar in your project lib directory. Also the mock module has been renamed to spring-test.jar.

The project compiled after the new jars were dropped into the project, but a couple of tests broke when running the Selenium functional tests during the build process. Upon further investigation we found that the suppressValidation(HttpServletRequest request) method in BaseCommandController had been deprecated in Spring 2.5 and was no longer called in the BaseCommandController class, so our controller that overrode that method was not being called. The fix was simple, we just overrode the suppressValidation(HttpServletRequest request, Object command, BindException errors) method signature and all functional tests were working again.

All in all the upgrade was quite easy which shows that the core Spring developers are doing a fantastic job at building an excellent framework. The experience also proves that writing tests gives you more confidence when it comes to upgrading your application’s module dependencies. If you have good test coverage then you will know early on in the development cycle of any change in behaviour that an upgraded module dependency may have on your application. So you don’t have to wait until UAT or worse, after the application goes live, for the change in behaviour to be raised as a defect.

On previous client projects that I have worked on, I have found applications that still used Java 1.4 and old versions of module and library dependencies. Not surprisingly these applications had poor test coverage which led me to believe that there is a high correlation between old and stale code bases and poor test coverage.

Therefore one of the reasons that a code base becomes outdated is due to fear, uncertainty and doubt (FUD) of what might happen to the application after an upgrade. If you don’t have any tests then the greater the cloud of FUD becomes and an increasing reluctance to upgrade application dependencies. Upgrades of project dependencies are necessary for developers to make use of new features, and to benefit from bug fixes and performance improvements. Avoiding frequent upgrades will incur a cost that we call tech debt, and it means going without the new features, bug fixes and performance improvements that a newer version of a library or module dependency provides. This leads to a reduction in productivity and quality that eventually translates into a dollar cost amount to the business.

The message is simple: write tests so that any change in application behaviour from future upgrades of module and library dependencies can be detected and resolved early in the development cycle. Do not ignore upgrades, as this will only add to your tech debt, and with any debt that doesn’t get serviced you end up paying a greater cost as time goes by.