Cost of porting vs. cost of continued development

I thought I’d take the occasion of OpenVMS turning 30 to share some thoughts about why I have OpenVMS experience on my resume. See, I once worked for a company that was severely stuck in OpenVMS land.

Now, when they switched to VMS (from I forget what… but you can’t buy one now) it wasn’t the world’s worst idea. It was in the eighties and OpenVMS compared quite well to everything else at that point in time. But in 2001, it wasn’t so great of an idea to be forced to live in lockstep with what DEC / Compaq / HP wanted to do with their legacy product.

I was not in an OpenVMS programming group and I was quite happy to have things that way. At the same time, I got to watch the architectural directions here and there without getting too upset about having to take sides and then having my side not win.

Now, about this particular company… it should be remembered that there were a number of simply brilliant programmers who had built some incredibly flexible software. Think about X windows that was happy to work over a 14.4 modem and on a 486 or some very unique OLAP databases that you still cannot buy off the shelf. These folks tended to be able to write stuff that was ahead of its time and continued to not get caught by most of the truly stupid ideas that went around. So… bright programmers.

This presented a problem for the company as OpenVMS started to really decline. See, most of the time, you have some crusty old COBOL or Fortran code that was awkwardly developed, with tons of arbitrary limitations and hardcoded variables. And it really ought to be replaced. You end up saying ”Gee, let’s replace it with clean modern code that a new BS CS grad would understand so we don’t need to worry about what happens when Bob kicks the bucket

No, this is a living codebase that was free of most obnoxious limits, with a bunch of artist developers who were very good at fixing things and moved it from a Fortran codebase, to a C codebase, to a C++ codebase, and then to a modern C++ codebase.

Oh, and I might add, this is a performance-sensitive system, so you can’t just move it to a little emulated virtual machine. The scalability of the whole company is directly related to the power of the latest OpenVMS machines.

This left them at a crossroads that they still, as far as I can tell, haven’t gotten out of. I don’t really know because I haven’t really asked anybody and it’s been long enough that anything really juicy has been forgotten.

Here’s the problem, the way I see it: For at least a decade, there has been a bunch of sources sucking away at productivity for the engineers. Because tools like debuggers, profilers, leak checkers, compilers, etc. were all much more mature on other platforms, engineers were some percentage less productive than they would be on another platform. Multiply that percentage by the average engineering salary, extend it over a decade, and you are starting to talk about some real money. Add to it the cost of compensation to hire the number of superstar programmers they needed to make it all work at all, and the increasing cost of recruiting people to work on OpenVMS and it gets even worse.

But it’s hidden. From their perception, they didn’t have to deal with ratty old libraries and were able to be more efficient for that reason. The problem is, the people who could have made that decision all had fond their perfect first job there and had been there for a long time. Most of them were simply not aware of how powerful modern development tools were, so they set the percentage of productivity-suck too low. I should reiterate that these are brilliant folks here — this was not a pointy-haired-boss sort of decision, they just couldn’t see the forest for the trees.

I was programming with Visual Studio, which has many problems, but at least has a pretty decent debugger, plus you have plenty of tools ready, so I would place the percentage of productivity-suck higher. In fact, I’d place it high enough to say that the company has silently wasted at least enough to rewrite the system at least once.

There were a lot of subtle social and software issues at play, such that even when they wanted to move off of OpenVMS, that effort was doomed, which I’m going to talk about in my next post…