So I've been working with Salesforce for about a year now, as a developer and consultant, and something I've been running into a lot lately is code rot: code that lives tucked away somewhere and never gets updated 'cuz it's working and it was made by someone who's no longer in the picture and nobody knows what it does. Or code that has ceased to be relevant or used for months/years, but no one's stopped to go in and remove it. Or that thing that happens when you have a whole bunch of different people doing work on your SF org, and they're all from different companies and have different standards and levels of skill and so on, and nobody wants to take the responsibility of updating or fixing somebody else's current or old code.

This can happen with any system really, but with SF, I think it's particularily vulnerable to this problem.  Being in the cloud and subscription base, SF is very attractive to companies who want to re-orient their IT department to other projects. (or, god forbid, cut costs by out sourcing some of the tech, or just bypass a controlling IT department all together)  It's very easy to use, and when you need to customize things, you hire consultants or contracters to come in and set things up.  But companies can end up going with a whole host of different individuals or teams, depending on availability and cost and skill set required, and you can end up with a bit of a rat's nest if they're not careful and do periodic audits of their customizations, installed apps, etc.

So as a consultant, what can you do?  The best thing to do is to do excellent work and provide great customer service so that it's only you and your team who needs to maintain the system and keep things clean. :) You can also do your best to educate the client, be they business users or IT admins/devs, so they know what the best practices are and the easy pitfalls that can be fallen into if they're not being careful.

But sometimes you're inheriting a system from a previous team, and if things are a mess, you'll have to try and convince the client that a clean-up is required.  Do an initial audit, find out how good/bad things are, identify what needs to be done and then present a prioritized list to the client so they get an idea of what they're dealing with.  This could potentially be phased out over the course of your client relationship and several projects - removing dead classes here, improving code coverage there - so it's not a big hit at the start.

Most importantly though, it shouldn't have to be said that you should be honest about what needs to be done.  Enough said. :)

Aside from that, what else can we do?  Follow best practices for architecting your code and customizations of course, but even beyond that, just think about the next guy coming in behind you.  Whether it's another developer from your team or someone else looking at your stuff long after you're gone, always do your best to write clean code and leave plenty of comments about what the code does.  Fill in those often-left-blank description fields on your custom objects. (yea, really!)

Coming into a project where you're dealing with code that some else wrote before you can be a trying experience.  I've been there too many times myself, so I'm always trying to "pay it forward" to the next programmer by commenting (sometimes over commenting) and leaving behind a code structure, naming convention, etc. that makes sense, or at least made sense to me at the time, and hopefully makes sense to the next developer to come through.  I even leave apologies behind in the comments when ever I resort to magic numbers or do something that might not be the best way in the future, but was the best way at the time.  This is always good practice, because you never know when that future developer might be you!

So in summary, help prevent code rot!  Do good work for your clients so they hire you back, educate them so they don't contribute to the problem, leave behind clean and well commented code so it'll be easier for someone to update and evaluate in the future.