Author: David Masri Founder & CEO

This is a lesson I learned early on in my career the hard way. Although I have no proof that people are doing this, I know it's incredibly common. Consider the following situation and think about how you would handle it. Be honest with yourself, (it's not like you have to tell anyone).

You are developing a complex integration to Salesforce and after weeks of hard work, you come across some edge case in your data that was not considered and has the potential to cause upheaval to your timeline. What do you do? Do you fess up, or ignore it and wait for the client to catch it in UAT?

The temptation to ignore the issue and pretend you never noticed it is very real. This is particularly true when you are already behind schedule or dealing with a difficult client who is going to ask a million questions and then insist on having a meeting with four other people to discuss the issue. If you ignore it, who would they know? When (if?) the defect is found later you can just say "Let me look into that". It's an edge case, maybe if won't even be found until the warrantee period is over and you'll be free of it!

It's my assertion that there is a large percentage of developers who keep their mouth shut and sweep the issue under the rug, i.e. bury the body. I know this happens when people give notice and are trying wrap things up in there last two weeks. The shit I have found after someone quits is ridicules. (They should admit they couldn't finish and then do a proper handover of open issues).

If you are one such developer, I urge you to resist the temptation to ignore the situation and do what you know is right. If you are burying bodies, you are trading in your professional reputation as someone who does quality work just to avoid a headache. People will think you actually missed the issue and think less of your capabilities (both coding and design). Whereas if you "confess" people may be annoyed at the moment but you will bolster your reputation as someone who doesn't let thing slip through the cracks, and as someone who is willing to do what's best for the project even at their own expense. Nothing builds trust more than proactively admitting a mistake, nothing.

If it is something that is easy to fix, but you want to avoid causing the upheaval and you know what the client will decide to do with a high degree of certainty, then fix your code, update your documents, and then send an e-mail (after hours, so you can use the excuse that you didn't want to wait until the morning and lose hours of work) that explains what found, you did and that you are open to discuss it, if needed. This situation falls under the "It's easier to obtain forgiveness than permission" strategy. Needless to say, there is only so many times you can do this before people get upset. And if you are told never to do this again, you'll have to stop (at least for this client). Never, ever take this approach with a production system.

If you are still not convinced to do the right thing, know this: Eventually, the body will be found, and the upheaval will happen. So, you may as well get it over with and get credit for finding the body, rather than getting blamed for the bad design.

If you are following the "Start Early" best practice, the chances of finding such an edge case so late in the game is greatly reduced.

This article is adapted from my book: Developing Data Migrations and Integrations with Salesforce.