Editor's Note

Calculating The Cost Of Change

• By Patrick Meader
• 02/01/2009

I curse fiercely. I berate myself for not taking better precautions. Then I curse some more as I try to rescue the file. Will it open in notepad, perhaps? Will a different USB port be able to see the portable storage device? Experience tells me I'm better off knuckling down and just getting to work, but I'm usually too worked up to sit down and start anew immediately. I should take up yoga or meditation, learn a calming mantra. A better man might seek solace from his spouse, but I don't want sympathy or empathy at such times. No, I want to break stuff, to throw the offending computer out the window. I want to smash things.

Given how much I hate to redo stuff, I know one thing definitively: I'd hate to be a developer. Having to revisit and rewrite a half-dozen applications every time the company that makes my software tools changes something would leave me feeling queasy; having to retool everything I've ever done because of far-reaching changes would mean a weeks-, if not months-long stream of invectives to make David Mamet blush. I'd be in a semi-permanent rage state, tucked away in a back office or closet so no one else would have to listen to me. It's one thing to redo something because I made an error; it's quite another to be forced to redo something because someone else makes a change that's in my "best interests," especially if that change alters how I must approach my job.

But such changes happen all too often in software development. In her column last issue (Ask Kathleen, "Windows Workflow Changes Direction," January 2009), Kathleen Dollard tackled the extensive changes Microsoft is making in the next version of Windows Workflow Foundation (WF). She noted how many of the changes planned for version 4 will break existing WF 3.5 applications, and urged that you put off developing new WF-based applications if you haven't begun creating them already. She also provided several tips for minimizing the transition to the next version of WF. In her opinion, developers will win over the long run, but she also acknowledges that the price to achieve these gains is steep.

This month's Letters to the Editor include a response to Dollard's article from Matt Fritz. Fritz laments the changes to WF, as well as other, similar types of changes that he's experienced as a Microsoft developer (see "Running the Development Treadmill,"). Fritz notes that he's a strong believer in the Microsoft development platform, but goes on to say that "using [developers] as beta and field testers ain't right. It costs us and our companies time and money."

He's right. These changes do carry a significant cost. The flip side of his argument is this: Does Microsoft save Fritz money in the long run by making these changes? The answer is: It depends. For some developers, the changes will pay for themselves handily over time; for others, the changes won't provide the same return, whether because the developer doesn't need the changes, or because the changes mean abandoning a platform or technology they've invested considerable time and energy learning and deploying.

One positive aspect of the changes to WF is that they're occurring before the product matured. Another positive aspect: WF is not a technology that's in widespread use, and the current implementation is lacking in significant ways that the next version will address. There's a reason more people don't use it now.

But what if you're one of those who made an investment in the current version of WF? Microsoft is consciously throwing away the efforts of the developers and companies it convinced to adopt this technology. It's penalizing its own best, most enthusiastic customers -- the people, in fact, who had paid money for WF. When discussing Microsoft's approach to WF with a couple advisors to VSM, the conversation would usually start with "Big Bad Microsoft" for doing this to its customers but eventually would swing back to discussing why someone would put an immature or little-used technology to work in a mission-critical scenario.

On the surface, this argument strikes me as bizarre. Are the companies Microsoft convinces to use its technologies culpable when Microsoft changes things up? You expect some risk when you use a beta or community technology preview technology. Maybe the same holds true for a version 1 product. We all know the adage that you shouldn't adopt a pre-version 3 product from Microsoft, but we don't actually mean it, do we? Regardless, that argument shouldn't be in play here: Microsoft is scrapping a version 3.5 product. The product hadn't achieved maturity, nor had it achieved widespread acceptance, but it seems unlikely you could see this coming if you were a company that relied on WF.

The changes that are occurring in WF wouldn't seem so significant if there weren't other examples of developers having to rework their applications because Microsoft made changes of a similar scope in other technologies. For example, the introduction of a .NET version of VB roiled the VB community for years, and we're still feeling the aftershocks of some of those design decisions. Microsoft was careful to note when it introduced a .NET version of VB that the existing code developers had written would still work. Similarly, WF 3.5 apps will continue to function. But the blunt truth is: Discontinuing a language or technology is a death sentence to future development for that language or technology, and even existing applications face hardware and other limits on their longevity. Sooner or later, developers will have to move on, whether they want to or because they have to. Even if existing apps continue to function or are maintained indefinitely, your ability to earn a living with that tool or technology is severely limited, and you incur an opportunity cost when you need to abandon what you're doing now for something else.

I'm ambivalent about what constitutes the proper balance between maintaining backward compatibility and introducing new features. I want the software I use to provide features that help me do my job better and save me time over the long run. It should also be noted that there's a cost to backward compatibility, especially in terms of application performance. As much as I hate to redo things or have to rework things to achieve functional equivalence, I'm willing to accept changes that break how things work now in exchange for a significant improvement in how things will work going forward -- especially when the reason for the change is compelling.

But the central issue is this: My notion of compelling doesn't always match that of the software's designers. What strikes a software developer as essential can strike me as capricious (Microsoft Office's ribbon, anyone?). It might be that a company could change its product so it serves 95 percent of its users better, but alienates me in the process. I just don't care how much the first group wins if the software becomes unusable for me. That's part of the equation that a company that creates software must consider. When a company bets I'll like a feature enough to not mind that it no longer works as it used to, that company places bets with my money, as well as its own. And I'd like a company that places bets with my money to do so at least as conservatively as I would. In the case of WF, Microsoft isn't just betting with other people's money; it's saying the chips those early adopters bought from Microsoft can never be redeemed. A company ought to be extremely careful about making such bets, because they represent a major withdrawal from the goodwill bank of their customers. Doing this even once can be enough to turn a customer against you, so a change that affects only one person in 20 can still have significant consequences. If a company does this routinely, it's only a matter of time until it affects all its customers.

What concerns me most about what occurred with WF are the implications these changes portend for the future for those who use Microsoft technologies. Today WF is a peripheral technology. There are people to whom it's important, but there are other technologies such as Office, Windows, or even VB that are not so peripheral. For example, Windows Communication Foundation is undergoing its own changes that I understand will have an -- admittedly less dramatic -- effect on backward compatibility. And Microsoft has announced that LINQ to SQL is basically shifting to something akin to maintenance mode, which is worrisome for many developers who see it as their only workable data solution at the moment. Sure, I expect something else, as yet unannounced, to take its place (Entity Framework?). But how many times will you as a developer have to go through this process? More to the point, how long will you suffer Microsoft to put you through this?