Code Does Not Hype

 Posted by on Nov 25, 2011  Add comments
Nov 252011

It is the story of my adult life. A VC dispatches me to some city to perform due diligence on a company he/she contemplates investing in. Upon arrival I meet the “reception committee.” It usually includes the CEO, the CTO and the CMO. Nine times out of ten the folks on the committee are intelligent, knowledgeable and accomplished. Moreover, they do their very best to charm me.

I still remember the reception committee from the due diligence on Tideway I did for Apax Partners some seven years ago. The folks were awesome. I am fairly certain they could convince birds to fly off the tree if they chose to apply their very many talents toward this end. I really don’t know whether Apax (who invested in Tideway) and BMC (who acquired Tideway at a later time) consider their investments in Tideway successful. But, take it from me: even the Royal Shakespeare Company would have been hard pressed to stage such a terrific act as the one played by Tideway for my benefit in 2004.

You might wonder what’s wrong with this picture? Spending a day or two in the company of smart people who do their utmost to explain the ‘secret sauce’ of their business design and their technological ‘recipes’ does not sound as too bad a way to make a living.

It is not. But, the thing that is wrong with this picture is that the reception committee is a marketing/sales committee in disguise. They are usually very aggressive in selling their company. Many times they hype it as if there was no tomorrow. Sorting the facts from the hype, as distinct from finding the deeper truths that will make the company click, is, well, tiresome.

When I was young and naive, I tried a few times to change the dynamics, telling the folks something like the following:

Look, guys. This is not about impressing me. This is about your “getting married” with the VC I represent for the next three years, or five years or whatever the investment horizon might be. If you accept this premise, the warts are as important as the attractive aspects of your product and the great success you have selling it.

It never worked. The minute I would finish my spiel I would see eyebrows raised and glances exchanged. I could almost hear the windmills of their minds turning in exasparation at my inability to grasp the rules of the game.

After a few awkward experiences trying to change the due diligence dynamics by stating what I considered to be the plain truth, I learned my lesson and stopped saying foolish things such as the lines cited above. Instead I started trying the “please learn from history” approach. When the marketing hype in the investor presentation hit the fan, I would say a few words along the following lines:

Well, you know, the VC I represent has a warehouse of great business plans that failed miserably. If history is any indication, what would you think could get your company in trouble?

Needless to say, this approach also did not work – I was flying again at the teeth of human nature. The typical answers I was getting were reminiscent of the advice I myself recieved many years ago as a senior in college before my first job interview: “if they ask you what your weaknesses are, just say you are too passionate about your work…”

But, over the past couple of years things have improved immensely for me and for my VC clients. The progress we as an industry made in technical debt techniques enables me to easily get over the marketing hype insofar as the code is concerned.  A company might claim that its team of development “tigers” is superior to the teams assembled by the late Steve Jobs, but such claims are not too credible when we find Cyclomatic Complexity numbers in the hundreds. As a matter of fact, some of the complexity numbers I witnessed in a recent engagement were higher than 2,000. With such complexity numbers, it is almost irrelevant whether the complexity is per class, per method or per file. Nor does it matter that the team proclaims to be on top of the latest and greatest in Scrum or some other software methods. To state it simply: the code sucks to the extent that almost nothing else matters.

Cutter is a pluralistic culture in the best sense of the word. The convictions and practices followed by one consultant need not be identical to those of another consultant. The Agile Practice offers a marketplace, expecting the client to determine which consulting style best fits his/her needs. I, as the practice director, do not make the choice between Alistair Coburn v.  Jens Coldewey v. Hubert Smits  – the client does.

So, I am not inclined to mandate that due diligence from Cutter must include technical debt analysis. But, I am fairly certain I personally will not be taking due diligence engagements unless technical debt analysis on a representative sample of the code is included as key piece of the due diligence.

The reason for so doing is very simple: code does not hype.


  6 Responses to “Code Does Not Hype”

  1. Interesting post.

    I’ve had to perform due diligence on acquisition targets in the past and I agree that code speaks for itself. It certainly levels the playing field when comparing the technical capability of one organization to another.

    On the other hand, I wonder if (in most cases) a great business model, satisfied customers, and/or intellectual property would trump technical capability. Such factors are often much harder to quantify, but might create more business leverage.

    I would love to meet a company that gets everything right, but if their code was full of “technical debt” and everything else looked good, I think I’d take that as an “opportunity” to replace the technical leadership and turn it around.

    Nonetheless, I completely agree that it’s certainly much better to find that out sooner rather than later.

    Regards. >Jeff

  2. avatar

    Thanks for the kind words, Jeff.

    I tend to think of technical debt in the due diligence context as kind of “necessary but not sufficient” condition.

    A high level of technical debt is a good enough reason in my book not to invest in a company. First, it represents a significant risk. Second, it is usually indicative of some deep pathology such as misalignment between the business and IT.

    Generally, when I see a great business model with an acceptable level of technical debt in the corresponding code, I tell my client something like “The investment decision needs to be primarily based on business considerations.”



  3. avatar

    Well I got a lot out of the DD that you did at Tideway. And out of the overall Tideway experience.

    Quite ironic a discussion about cyclomatic complexity as much of Tideway software focused on graph manipulation. It certainly showed that there’s so much uncertainty around how information systems hang together that a bottom up approach to trying to identify any model is challenging.

    Personally, I find that key issue around technical due diligence is in understanding how the engineering and any other delivery functions integrates with however the business learns about its potential markets, including how well shared are the views on the longevity of the current code base.

    If the investment target is pushing the message that it’s existing IP can deliver revenue, AS-IS, then tech debt is clearly very important. However, if the target is looking to build the product / service that will generate the value, the issue is whether there’s an awareness of the need to manage technical debt in the next phase, and how that will be done, but it may not have been well managed to date.

  4. avatar

    Hi Tim:

    Your good point about the coincidence that both Tideway and Cyclomatic Complexity are based on graph theory is, I believe, true in very many cases. Only a very small number of core problems exists. Wired the way we are as human beings, we solve them time and time again in the various domains of our activity.

    Here is an example: some years ago colleague Chris Sterling and I did technical debt analysis on a Governance, Risk and Compliance (GRC) company. As part of it we produced a bunch of heatmaps such as Cyclomatic Complexity v. Unit Test Coverage. The VC to whom we presented our report took a look at the heatmaps and said something like “you guys would be a perfect fit for this company; you might not realize it, but you are actually doing GRC on code.”



  5. […] here for additional thoughts on the subject and its […]

  6. avatar

    I love that approach. Have you done any DD using that approach or have you asked? Would be curious to the response.



 Leave a Reply

You may use these HTML tags and attributes: <a href="" title=""> <abbr title=""> <acronym title=""> <b> <blockquote cite=""> <cite> <code> <del datetime=""> <em> <i> <q cite=""> <s> <strike> <strong>