Due Diligence and Code Comments

This is the silly tale of a strange due diligence process I experienced. It happened several years ago but I couldn’t talk about it at the time. 

I’ve been on both sides of the technical due diligence table, and I’ve always felt that being reviewed is easy – you simply tell the truth when asked about the software and how it’s built. Anything else can get you into trouble. It is the reviewer who has the difficult job. Someone wants to buy or invest in a company and they are depending on you to help determine the fair value. You have to look at the development methodology, the design, the architecture, the configuration management practices, the licenses, and basically ferret out any problems and risks to ensure the company is a good investment.

A few years ago I was on the receiving end of the review. The first thing the guy wanted to do was open up a source code file. I pick one and open it on the screen. The conversation goes like this:

Him: I don’t see any comments in the code.

Me: Nope!

Him: Ok, let’s take a look at this file. Hmm, I don’t see any comments in here, either!

Me: Umm .. no .. no comments.

Him: Ok, let’s take a look at this file here. Well, well, well. It doesn’t look like you guys write any comments at all!

Me: Honestly - we try to avoid commenting code.

Him (horrified): What? How on earth does anyone know what the code is doing?

Me (stunned): Well, we figure out what the code is doing .. by  .. um .. reading .. the  .. code.

There are people who believe that all code should be accompanied by comments (an undergrad professor come to mind), but by the turn of the century I had hoped that most people understood comments to only be used as a “here be dragons” sign. If you are depending on comments to make code consumable - you’ve already lost the battle. Sure, there are exceptions for exceptional code – like code written to work around platform bugs, code optimized for speed, and the comments that feed javadoc and intellisense for a public API, but for the most part code that requires comments to make itself maintainable is bad code. This isn’t a recent trend. The Elements Of Programming Style said in 1978:

Don’t comment bad code – rewrite it.

Eventually the business deal fell through, but it wasn’t due to the lack of comments. The company walked away from the money the investors were willing to offer. A due diligence process, like a job interview, works in both directions. In this case the competency of the due diligence team didn’t instill the confidence needed to sell them a piece of ownership.