Bob On Development

Back in the days before dirt was invented — sometime in 2002 — Microsoft released version 1.0 of the .NET platform along with Visual Studio 2002. Among the technologies provided was an RPC stack called .NET Remoting, or Remoting for short.

Remoting was, like everything else in .NET, promoted like the Second Coming. It was the greatest thing since sliced bread.

I had a project that involved orchestrating a lot of data acquisition, conversion and scrubbing tasks on about a dozen PCs, and Remoting was absolutely the perfect solution. It worked absolutely great. The project was a complete success. With a little work, I had a complete workflow system with fabulous fault tolerance, even though one of the third-party applications called by each worker machine was notoriously temperamental.

Now that the project is “in the wild” it should serve my client well for the next dozen years or so.

Except for one problem: It’s obsolete already.

On a timeline that can only mean that Remoting was nothing but a stop-gap measure all along, Microsoft released a completely new and incompatible API for RPC work, the Windows Communication Framework, or WCF. Remoting is still in the .NET framework, and probably will be for the foreseeable future. But it has been sidelined and is now officially a Second Class Citizen. And all this happened in considerably less than four short years — two, if you count technology previews.

I’m not saying WCF is a Bad Thing. In fact, it looks like pretty good stuff. But consider what has happened here:

1. A small business invested scarce funds to produce a solution and expects (reasonably, I think) to get a return on that investment for many years with minimal additional costs.

2. Technically, they will get just that, but .NET developers who haven’t happened to work on Remoting in the past (including every new developer minted after about 2006) will know nothing about it. And likely, even those like myself who have experience with it, will be rusty. In addition, no new work will probably be done on Remoting by Microsoft, so if my client needs to integrate with future technology they may be forced to do a rewrite much sooner than they otherwise would have. If any bugs get introduced into Remoting, they are less likely to get caught and fixed quickly.. And so on.

Is this a big deal? Arguably, no. But it illustrates a fact of life that bullet-point-mongers in marketing seem to keep forgetting: no matter how great a given new technology is, the marketplace can only absorb it so fast.

There are limits to how many times per year a developer can retrain; actual work does occasionally have to get done.

There are also limits to how many platforms any developer can simultaneously be proficient at. It’s one thing if core functionality available in 2000 still works in 2006 and whatever has been bolted on since can be learned and leveraged as needed; it’s another thing if (as is the case with RPC) there’s been both a platform change and an API change in the same time frame.

Would I have handled this particular instance differently? Yes. In 2002 I would have given customers guidance about Remoting — that it was a stopgap technology and that a more comprehensive and flexible framework was under development for release three or four years hence. Then customers could make decisions and plans in the full light of reality rather than under the burden of marketing claims.

Of course, that’s never going to happen, but I can dream. I’d sure be nice if vendors were more respectful of the concept that when you provide a platform, it needs to provide a reasonable application life cycle for the things it supports. The lower level the platform, the longer that cycle needs to be. The only thing with a longer life cycle than an API would be the OS infrastructure itself.

This doesn’t mean the vendor can’t innovate within that framework, but they should consider it a personal failure if they have to needlessly pull the entire rug out from under customers. You might be forced to do that if, say, a competitor came up with something better and you had to match or surpass it to get the mindshare and momentum back in your court. But that’s making your problems your customer’s problems, which ultimately isn’t good business.

Sometimes when it comes to keeping up with technology churn like this, I feel like the Dutch boy with his fingers in the dike, trying to plug leak after leak. This isn’t because I’m old and set in my ways, or trying to Keep Everything the Same. I have, after all, willingly reinvented myself at least four times in my career, in the name of staying informed and competent. The transition from procedural to object-oriented development comes to mind, for example.

But there’s a balance to be had. There seems to be an ethos today that developers are somehow failing to Keep Up if they don’t attend, each week, at least one webcast about some vendor’s Latest and Greatest New Thing. Don’t believe it. Vendors just know we are suckers for new things, that’s all.

Instead of chasing every New Thing that comes along, prioritize relentlessly based on what you can get done for your clients effectively over time. Hint: this generally doesn’t have much to do with being on the Bleeding Edge 110% of the time.