All your talk about why bad code might exist does NOTHING to suggest code offsets is a solution.

I’m actually amused how much you are defending the businessman’s right to produce and leave in place bad code. Could that be because it benefits your own business model?

Best practices dictate that all software changes are to be sponsored, assessed, reviewed, tested, and then signed-off. Do you skip some of these processes, or do your stakeholders, analysts, programmers, and testers have that much idle time? Or perhaps you’ve never worked in a regulated environment where application functionality can’t just change at the whim of some coder?

It’s one thing if the module is being altered for another change, but that’s rare relative to the volume of changed code. Haphazardly implementing changes (good or bad) leads to far worse consequences than idle bad code.

I agree with EdLeafe: if a business would rather run bad code than fix it they deserve what they get. Paying for absolution solves nothing.

Fix bad code or replace it or expose it. There is no absolution!

And, yes, I have been in positions that required me to authorize the expense/effort to remedy bad code. It was NEVER a hard decision to do so. If your company won’t – don’t complain when that code is exploited. Absolution via offsets won’t save you!

It’s a joke. Really.

Carbon credits are an effort to affix a cost to wasteful energy use in order to provide an economic incentive to become more efficient. There is already a cost to crappy code: failures, delays, maintenance nightmares, staff turnover… if a business can afford to run on crappy code, then more power to ‘em! They aren’t affecting anyone but themselves.

This post was mentioned on Twitter by rjamestaylor: CodeOffsets.com: Parody, prank or publicity stunt? Anyway I look at it, it stinks: http://bit.ly/8NTTM6...

I can vomit in a text editor and as long as it works and I buy enough offsets, its ok to ship and use?

Sign me up, I’ll never have to actually write code again! Hey perl might actually be a useful language now.

Seriously though the idea of buying code offsets is ludicrous. Bad code is out there and it should be the lifelong goal of every developer to end as many bugs lives as possible. (And yes, I consider bad code a bug.) The reason so many “off-the-shelf” software systems are a complete disaster to actually use is because there wasn’t a business case to fix it.

I’m all for supporting the projects the “offsets” end up at, but really why not just donate directly.

In my opinion the idea of code offsets are just a joke, ha, ha, you wrote crappy code, here is your offset, oh by the way there is a new tracker item assigned to you to fix it.

As far as always fixing bad code, I do not always recommend diving in and fixing it. But, yes, fixing is first. WordPress fixes its code. PHP fixes its code. Red Hat fixes its code (among many others). This is a commitment worth keeping. If not optimal or possible my next recommendation is ditching the bad code.

Regardless what one does with bad code without fixing it it remains BAD. Assuaging guilt by contributing money to other unrelated projects does nothing to stop bad code in use today. So, to me, yes, you’re completely off-base. No offense meant.

I’d rather contribute to projects exposing existing bad code such as milw0rm.com or SecurityFocus. That at least publicizes the dangers of existing vulnerable code in use today.

Tackle the problem of bad code directly.

Bad Code is almost always Working Code that’s poorly implemented and expensive to maintain. Are you really suggesting that we just dive in and fix Bad Code whenever we see it?

Where’s the business case for that? Do you truly believe it’s worth the risk of changing an application *solely* for the purpose of refactoring code? How can you possibly make the business case for that? What, risk failure now as to potentially save on maintenance costs later? Have you ever had to make a business descision for software changes?

Or am I completely off-base here, and you seem to believe that all Working Code must be Good Code because it’s working? Ask any programmer who’s had to maintain code, and he will tell you that’s not the case.

Those of us grounded in reality understand that Bad Code is often permanent. Once it ships, once it’s stamped on a device, once it hits production, there is no going back. The code is bad, but it works. That doesn’t mean it’s right.