Programming - For Better or Worse
- Lessons Learned, Episode 23
In my last "real" job, I oversaw one programmer who specialized in COBOL and the programs running on our HP 3000 mini, and one programmer who specialized in SQL running on the brand new Windows Servers. I also managed two outsourced programmers who were building our new service entirely in C/C++ and SQL on the Windows platform.
There has always been a lot of money in creating customized programs. In fact, that's pretty much why computers existed from their founding until the 1990's. There were a few general-purpose programs, like word processors, but they didn't dominate the market. Custom built programs and databases were the primary reason businesses bought computers.
The part of this process I enjoyed most was database design. You would never hire me to do the programming because it would be inefficient, but I could visualize the databases, how they interacted, and all the steps to get information in and out of them. After all, that's what the real work of my graduate degrees was all about - since my field was political and social research.
So, when I started my first consulting business, "programming" came with me. I found lots of clients that had been sold various customized database programs over the previous ten years (or more). And just as with the hardware and software, these programs had been sold and then abandoned. The programmers were hard to get ahold of, and only interested in new jobs rather than maintaining the installed base.
Worst of all: When patches and updates were applied to hardware, operating systems, and related software, these old programs began to have failures. This is inevitable when the programs are not updated but everything around them is.
I'd come from a world where annual maintenance was roughly 20-25% of the purchase price of the programming. And while that was a painful price to pay, it meant that my stuff got fixed fast when there was a problem. Now that I was on the selling side of the equation, that maintenance seemed like a better deal.
I tip-toed into programming by fixing things here and there, which required me to hire hourly programmers. As a result, there wasn't much profit. Quickly, I turned to updating programs. This was my most direct recent experience.
We took old programs, like DBase IV databases, and converted them into Microsoft SQL, C+, and even Access if needed. Updating old Access databases to SQL was the most fun.
Before long, my old SQL programmer Bill came calling, and I hired him right away. We knew we worked well together. I knew he understood a very complex environment, and we trusted each other.
For about five years, we designed and he built a series of fresh from-the-ground-up systems that made clients more efficient, and extremely sticky due to the (reasonable) twenty percent maintenance fees we charged. We actually charged a declining fee over time as the likelihood of bugs appearing went down significantly with use.
Just as with any maintenance contract, we applied all the necessary patches and fixes. So occasional bugs were introduced and fixed. But this was easily covered by the maintenance fees. And it kept us fresh in the clients' minds.
And then Bill had a stroke.
Apparently, it's common that stroke survivors temporarily lose the ability to read. That's what happened to Bill. He could touch-type, but he couldn't read what he'd typed. And since most errors in programming boil down to typos, he was unable to work for some time.
In the meantime, I had a couple of big projects underway, a new one sold, and several under maintenance. So I had to have a programmer! I interviewed a few candidates and hired Greg.
Greg worked out great. Clients loved him. He was more expensive, but he did top-rate work. And then, just after his first year anniversary, he took me to lunch. He told me that he had had a mild heart attack the week before I hired him!
Greg was about forty at the time, so very young for a heart attack. And he felt guilty for hiding it, but he knew that I'd just lost a programmer to a stroke. What he didn't know is that my father had his first heart attack at age forty and died of a heart attack at age fifty. So this really made me sit down and think.
In the meantime, I had hired John to retool and modernize all of our web sites. (That's another story for another blog post.) John could handle some straight-forward C+ coding, but his love was on the Joomla/HTML/CSS side of things. This functionality allowed us to significantly improve the visual appeal of our database work without relying on a series of "outside" web designers.
We continued to do programming work together, but I gradually stopped signing new programming contracts. We did take on some new projects with existing clients, but gradually let that part of the business fade away.
My reasoning was two-fold. First, *I* could not do this work, so I had to rely on employees or contractors. Second, having managed programmers for about ten years, I also realized that I needed a team that worked well together and was large enough to both assist each other and allow team members to take vacations and fill in for each other.
Rather than take my IT infrastructure business off on a tangent, I decided get back to my primary mission and move away from programming as a side business. It wasn't my passion, and I was distracting myself by trying to run both sides of the business.
This is not the only time I decided to shrink my offering. It felt like I was at a crossroads: Either grow the programming business or get out. So, I handed off the clients to one of the programmers to manage, and I contracted for support for existing maintenance agreements, knowing they would gradually fade away with time.
Sometimes, a source of income can grow to be a separate, profitable division within your company. But you should always understand the commitment you're willing to make. The more you "stick to your knitting" and focus on what you do best, the more success you'll have going forward.
For me, moving away from programming made the most sense. And, in the end, it made the most money.
All comments welcome.
-----
Episode 23
This Episode is part of the ongoing Lessons Learned series. For all the information, and an index of Lessons Learned episodes, go to the Lessons Learned Page. https://blog.smallbizthoughts.com/p/lessons-learned-blog-series.html
Leave comments and questions below. And join me next week, right here.
Subscribe to the blog so you don't miss a thing.
:-)