% fortune -ae paul murphy

Switching costs

Just recently, a "Dr. Dog", used his own blog to respond at length to my comment on some staffing cost consequences of using open source in development. Here's part of what he had to say:

In for a penny's worth of rant, in for a pound I guess. "Paul" [a pseudonym] lays down the track that using Sun SunRays is cheaper than using Windows systems in a ZD Net article. I've seen this argument many times before and I won't go there, though Paul does. The real answer is it just depends on factors too numerous to mention. But my overall impression today is that common based hardware/software solutions rarely go above 30% of total system cost. The balance is eaten up in labor, which is the crux of Paul's argument.

What the article essentially misses is the nut of the problem: switch costs. Even if the analysis shows that SunRay's are say 15% cheaper over a 5 year life than Windoze are the switch costs included? That is has the additional contract labor been added to cover that period from about 40% penetration to completion covered while you operate two platforms in tandem? If you aren't [concerned?] the CFO will be. Have the valuation costs for shoving the old stuff out the door been covered? The depreciation that has to be recaptured? The port cost for all the files? It goes on and on.

I have seen the numbers on this kind of proposal from Sun. Not once but three times. [They're a persistent bunch.] Do they add up? Sure do. But the savings are so razor thin that if you look at the risk factors involved one really wonders if it is worth taking the leap. The risk factors increase linearly the bigger the firm. The punch line? Don't look for wholesale Linux adoption from the NYSE crowd at the desktop. Or to Macs for that matter.

I don't know who "Dr. Dog" is and I don't really want to pick on him, but what I found interesting is that he not only manages to sqeeze all three major misconceptions driving people to simply continue poor desktop choices into one short comment here - but somehow finds room to throw in a few red herrings and non sequitors too.

First, he assumes that arguments about changing the desktop hardware from PC clients to Sun Rays are directly and necessarily related to arguments about changing desktop applications.

This is wrong. In reality these decisions are usually made together but are different. You could, for example, implement Sun's virtual desktop infrastructure without making any decisions about what applications you run on those desktops - putting in Sun Rays today, for example, while continuing to support only Windows desktop applications.

What you'll find, when you do this, is that things that were utterly impractical in the all Wintel world become much easier. For example, switching half your users to OpenOffice in the typical Wintel client-server environment is possible but often technically and managerially impractical - but doing it when everybody's running on Sun Rays is both technically trivial and much easier to sell because you can give users, and user managers, complete freedom of choice in the matter.

He assumes, further, that running some Sun Rays with some Windows applications requires more manpower than running an all Windows applications load entirely on Windows servers and desktops. Again, this is simply wrong: as soon as you migrate at least some desktops to Sun Rays, you can redeploy your former desktop OS support dollars to other uses - and because the server side workload is so limited, all but the smallest businesses end up "in the black" on the manpower transition within a month or two of starting.

Notice too that he draws a conclusion from thin air here claiming that the "punch line" on switching costs is that the financial community won't be switching to Linux or the Mac - something that may be true, but has no logical or causal relationship to either the use of, or the usage costs of, Sun Ray.

Secondly he makes the classic sunk cost error railed against in every introductory BComm financial management class.

What he says about paying out the PC investment by using the things is simply wrong: when you compare two decisions on financial grounds you estimate the net present value of the future costs associated with each decision and pick the bigger one - regardless of how much money you've already sunk into the loser.

Many people, including a lot of Finance people who should know better, have trouble understanding this at the intuitive level. If you're in that group, try this analogy: imagine that you've bet big on a horse that then dropped dead halfway down the track in the first of two races it's entered in - and then ask how smart someone would be to double down on it in the next race.

Oddly, I don't think it's obvious how you avoid this trap in real life because there genuinely are switching costs - I can tell you from personal experience that labelling unrecovered depreciation a fiction doesn't endear you to the Finance people - so my MBA deprecated advice is usually to schedule change into the evergreen program - and not because it makes sense, but because it avoids making enemies.

And if all that isn't bad enough, he does the classic myopic IT guy thing too: limiting his view of risk to things that directly affect IT success - things like software, hardware, IT management, and user acceptance failures.

In reality the risks that IT should be most concerned about are risks to the business - not risks to IT careers. The Sun Ray shines at reducing business risk - but he attacks it as increasing IT risks and thus puts himself ahead of the business IT is supposed to serve.

Again, the argument is dead wrong but dirt common, and very hard to beat in real life because IT people, like everybody else, want to succeed in their careers - and doing that in IT requires failure, not success. Thus he's dead wrong about Sun Ray increasing IT risk, but right that it increases IT career risk because systems that work quickly become invisible to senior management - thus leading to reduced personal visibility, reduced budgets, and long term reductions in career opportunities for IT managers.

So what's the bottom line? if you're making any of these mistakes: confusing the application delivery process with the applications environment, counting sunk costs toward future choices, or focusing on internal IT or personal risk instead of risk to the business - then it's time to rethink your position.


Paul Murphy wrote and published The Unix Guide to Defenestration. Murphy is a 25-year veteran of the I.T. consulting industry, specializing in Unix and Unix-related management issues.