New Venture Lab: Equipping Christian Entrepreneurs

I was recently looking at a business plan involving software that was several years old and was being repositioned to sell into a new market segment. While discussing the plan with our interns, I was immediately transported back in my memory to twelve years ago when I acquired a software company and learned many painful lessons along the way.

It was my very first acquisition, my very first time in the software industry, and my very first time as a CEO. (Looking back on that entire experience I can now see the foolishness of tackling a new process, a new industry and a new role all at once.)

The company was actually a division of a Fortune 500 company that was being spun off because the new CEO felt it was no longer core to their corporate strategy. The good news was that the seller was serious about selling and didn't experience all the flip-flops and mood swings that an owner/operator will typically experience when selling their company due to their emotional entanglement in the business.

The negotiations went fairly quickly and I was given the opportunity to perform due diligence, or "investigate" the company, its products and its employees. The market seemed to have a lot of potential, the employees seemed eager to stay on with the new company and the software, while not perfect, seemed to have tremendous functionality. The software had been written over the preceding five years to replace a legacy mid-frame software program.

I hired a software consultant "expert" to check out the software code and meet with the software development and support team. He gave me a detailed written report and gave me a thumbs up, which I naively accepted and plunged headlong into the deal.

As it turns out, there were a lot of questions about the software that I did not know enough to ask and as the next few years unfolded I came to regret ever doing the deal, but my tuition, while expensive, provided me an education that I was able to use over and over again in building other software companies.

The key nuggets of my learning included the following:

• The "tool kit" used to develop the software is critically important. In this case, the software was written in proprietary code on top of a proprietary, little known database software program. This translated into code that proved very difficult to find qualified employees and contractors to help us evolve and support. It also led to a very rough upgrade path when the small software company completely rewrote their tool kit in a new version and we had to rewrite all of our reports for clients nationwide - a very time-consuming and expensive proposition.

• Software toolkits evolve rapidly and can be easily leapfrogged by better "substitute" toolkits in a very short period of time. While we continued to invest in adding functionality and fixing bugs in our software, it became painfully clear that with the newer and better development tool kits that becoming available, we could completely rewrite the software cheaper and easier than we could fix the old software. This was mostly due to the fact that the newer and better toolkits had automated more and more of the core code development into modules that could just be snapped into place rather than written line by line. Software "configurability" was becoming the standard, rather than writing custom code. Even now I am very aware that any time I embark on a new software development project, the time and effort I will spend developing it will be cut in half only one or two years later.

• The more lines of code, the bigger the headache. I didn't know enough at the time to ask how many lines of code the software contained. As it turned out, it was a massive code base that required a tremendous maintenance and quality assurance effort just to keep it running. The more custom code, the harder it is to test. The more custom code, the harder it is to "tweak" a process because it is harder to follow all the logic trails to make sure you got it right.

• Documentation is a must. As it turned out we had good manuals for our customer users, but very poor developer documentation. As is typical, the developer did not last long and left us with code that was very difficult for any other developer to step into.

• The Quality of a programmer can vary by 10X. Shortly after I acquired the company, I read the book "The Mythical Man Month," a book written about the OS/360 software development at IBM in the 1960's and 1970's. One of the points in the book is that a really good programmer can be ten times better at writing code than a poor programmer. This was a fact that I saw play out in front of my eyes. I finally found a skilled programmer to help us upgrade and evolve the application. He was very efficient in his coding and could write a routine in just a few lines of code that took the previous programmer a full page of code to write. His expert assessment of our code was that it was a can of worms and very difficult to improve. It was not exactly what I was hoping to hear. His billing rate was three times higher than the previous programmer, but he was several times more efficient, so overall, he was a real bargain.

We eventually sold the company after ten years (I ran it for a few years and then hired a CEO to run it), but it was not exactly a stellar success. The disappointing return on the investment was primarily due to the old code that had become a can of worms and an installed base that was difficult to support and keep happy.

As I came out of my flashback and glanced again at the plan to take some old software code and repurpose it into a new market segment, I shook my head and told our interns of my lessons learned.

My bottom line assessment on the business plan was this: it would be far easier and cheaper to sit down with an excellent software architect, a business process expert and an excellent toolkit and develop a world-class, web-based software platform that would be worlds better than some clunky old client/server application written a decade ago that was being patched up for a different purpose.

What I should have done on my initial acquisition years ago was to sit down and figure out how much time and money it would take to develop a "killer app" for my target industry and compare that to acquiring the software company in question. That would have been an interesting analysis and one that would almost certainly led me to abandoning the acquisition.

Of course there are benefits to acquiring a company, but when it comes to acquiring or investing in a software company - where the primary asset is the software itself - be sure to do your homework.