CodeOffsets.com aims to assuage the guilt of programmers for bad coding practices by allowing offenders to contribute money towards quality open source projects. From their own webpage:
The Bad Code Offset provides a convenient and rational approach for balancing out the bad code we all have created at one time or another throughout our lifetime—even when we can’t go back and fix it directly.
As a programmer I find the idea of code offsets offensive and near to insulting.
The best way to solve bad code is to report it (if not open source) or patch it. If a project is unwilling to fix it, quit using/recommending it.
Some have suggested that Code Offsets are really a ironic joke about the similar fallacy of carbon offsets (or religious indulgences which predate both).
Better efforts included the re-write of Matt’s Scripts archive, which were security-riddled perl-cgi scripts popular in the early days of the web. The project called “Not Matt’s Scripts” aimed to be drop-in replacements for these buggy scripts used on sites everywhere. Matt even endorsed the project (mostly)!
I personally wouldn’t want to participate in a project that assuages guilt without solving the real problem! Fix the code or ditch it!
{ 2 trackbacks }
{ 7 comments }
“offensive and near to insulting”. Come on, really?
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.
Thanks for the reply. I assume you’re with the codeoffsets.com project?
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.
So let me get this straight.
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.
Wow, it looks like we might need Sense of Humor credits here.
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.
The idea that fixing or ditching bad code is a worse business model than paying to assuage coder guilt over letting bad code exist is laughable – actually it’s worse – it’s irresponsible.
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!
In addition to entirely lacking a sense of humor, you seem to misunderstand that fact that Good Code isn’t always Working Code, Bad Code is usually Working Code (often *perfectly* working, i.e. passing all test cases), and that it is *irresponsible* to change production code simply for clean-up purposes.
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.
Alex – personal insults aside – code with security vulnerabilities is NOT working code. If a company deems it unimportant to fix code with security holes it is being irresponsible. Irresponsible companies exist! That doesn’t mean being irresponsible is a business model worth emulating.
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?
Comments on this entry are closed.