Geeks With Blogs
Ulterior Motive Lounge UML Comics and more from Martin L. Shoemaker (The UML Guy),
Offering UML Instruction and Consulting for your projects and teams.

AT ONE TIME the Horse had the plain entirely to himself. Then a Stag intruded into his domain and shared his pasture. The Horse, desiring to revenge himself on the stranger, asked a man if he were willing to help him in punishing the Stag. The man replied that if the Horse would receive a bit in his mouth and agree to carry him, he would contrive effective weapons against the Stag. The Horse consented and allowed the man to mount him. From that hour he found that instead of obtaining revenge on the Stag, he had enslaved himself to the service of man.

Aesop's lesson here is about the dangers of Lock In: once you choose a tool or platform, you've surrendered some control to that tool or platform. You need to be wary of Lock In. A tool may lack features you need, or may provide them is a substandard form. A tool can force you to take steps and work in ways that may be wrong for your project, or may not fit your skill set. And Lock In can also leave you stranded if your tool supplier goes out of business; and it can leave you just as stranded if your tool supplier comes up with a new tool and stops supporting the old one. So put not your faith in tools!

But doesn't that conflict with The Boy and the Nettles, where Aesop advised you…

If you choose a platform, use the platform. Grasp the nettle boldly.


Well, there's not a conflict there, so much as a tension between two forces. It's important to know that both forces are at work: the benefits of a tool, and the risks of a tool. You don't get one without the other. The key is to find the tool with the most benefits for your project and the fewest risks for your project; and then study the risks, see how they affect you, and decide a plan to work around them. Find the right balance of benefits vs. risk.

Let's look at our three risk areas in more detail: lack of features, lack of fit, and lack of support.

Tool Risk: Lack of Features

One way to have the fewest risks is to choose a tool with a large number of features and capabilities. As I explained in The Boy and The Nettles, that's one benefit of .NET development: no matter what common development task you can name, it's in there. For .NET 1.0, I made a presentation called .NET is an Elephant. With art courtesy of my lovely wife Sandy, I created this image:

NET Elephant


Figure 3: .NET is an Elephant

My point was to convey that there's a lot in .NET. If I were to actually list all of the feature sets, you wouldn't see the elephant for the words.

And then with .NET 2.0, I expanded the picture:

NET Elephant 2


Figure 4: .NET is a Whole Lotta Elephants!

And again, I would need a whole circus parade to list even some of the .NET 2.0 features. And then 3.0, and 3.5, and WPF, and WCF, and WF, and Live, and Silverlight, and HealthVault, and Windows Automotive, and… Well, suffice it to say, lack of feature support should not be a worry for .NET developers. (Lack of time to learn them all, on the other hand…)

And you can find rich-featured tools for other platforms as well. Don't ask me for guidance! I've got too much to learn just keeping up with .NET. I can read up on what's being done with other tools and platforms, but there's no time for me to gain deep knowledge. (I would start by asking Dianne Marsh.)

Now a separate question is whether your tool provides good support for the feature you need. I won't repeat myself on the choices involved there. Go back and read The Boy and The Nettles for my advice on that.

Tool Risk: Lack of Fit

If your tool doesn't fit your problem or your constraints, that can be difficult; but often, you can create a technological bridge for this. It may not be efficient; but often, it's easier and faster than creating your own solution from scratch. And it may be more efficient, as well, unless you're a genius who's sure you can come up with a better solution right out of the gate.

As an example, for a while there was a fairly thriving consulting niche for people who could produce PDF files from online forms. Users would fill in the forms, the system would create a PDF, and then the system would either display the PDF in a Web page or email it to the user. At the time, the most popular and common tool for building PDFs was Adobe's Acrobat Writer; but that was a desktop application, and the system required access via the Web. So the niche was in creating Web server plug-ins (using various technologies) that would feed documents to Acrobat Writer, gather up the results, and return them to the server. Today, there are canned solutions for this; but at the time, any solution was better than none. Acrobat Writer didn't fit the Web, but we could make it fit.

But if your tool doesn't fit your team, that's a more serious problem. Don't assume your team can learn a new tool too quickly. Nothing against your team, it's just that power tools usually have a lot of depth and complexity beneath an easy, appealing surface. So make sure you give your team learning time. Get them books. Send them to conferences. And yes, though I have self interest in saying so, send them to classes! Sometimes an expert can show them in five minutes what they would spend weeks digging out on their own.

And if you can find them, hire some experts to come in as tool gurus or mentors.

Tool Risk: Lack of Support

Sometimes managers worry, "What if our tool vendor goes out of business?" If you're using .NET, I think this is a very low risk. A market cap of $340 billion doesn't disappear overnight. In fact, I'll make a bold prediction right now: Microsoft will still be a significant factor in the software development market ten years from now. I made that prediction a decade ago, and people laughed at me. They were sure that Linux was going to "finally kill Microsoft". (You have to imagine the glee in their eyes when they said this…) I was right, and they were wrong. Well, I'm predicting it again: no company is guaranteed to last forever (Lloyd's of London notwithstanding), but Microsoft will still be big a decade from now. I've got a free dinner I'm willing to bet on it. Any takers?

So Microsoft will still be around; but what if they stop supporting .NET? That's a more serious concern, since Microsoft has rather radically overhauled their core technologies over the past decade. Large companies with long-range planning like to amortize strategic technology investments over as long as 15 years! Well, Microsoft usually phases out support for old technologies over 10 years, and stops most active support over 5, give or take. And the "dominance" of a given Microsoft OS is even shorter. For example, they have released seven consumer OSes in the last 15 years: Windows 3.0, Windows 3.1 (different enough that I think it deserves to be listed separately), Windows 95, Windows 98, Windows Millenium Edition (painful flashbacks…), Windows XP Home, and Windows Vista Home. That's barely two years each!

But the underlying technologies are changing more slowly: 95, 98, and ME had a lot of common core; and XP and Vista are first cousins at the farthest. If I write .NET code, most of what I wrote works equally well on XP as on Vista.

And beyond that, I can offer only this observation, somewhere between faith and prediction: in my recent experience, when a new Microsoft tool makes an old one obsolete, I find that the new one is superior on so many fronts that it's a clear benefit to adopt it; and one of those fronts is that it's easier to learn and adopt. So instead of feeling that I might "lose time" by investing in and using new tools that may go away, I find that I gain time by using something that's easier and leads to a solution faster than the previous tools I was using. Plus the next new tools will usually build on pieces of the current new tools, so time spent learning the tools today usually pays off with the tools tomorrow.

But you say, "But we're a Mac shop!" Well, Apple will probably last the decade, too, so the same basic principles apply.

"But unlike Martin, I'm not a Microsoft toadie," you say. Or "But our critical tool provider is a lot smaller than Microsoft." Well, there are no guaranteed answers. There's no guarantee your company will be around in 10 years to support your customers. And there's almost a guarantee that whoever you assign to write your own solutions won't be around in 10 years to maintain it. 5 years is iffy. And let's be honest: unless it's a core piece of the code that the developers spend most of their time in, they'll forget how it works in six months. Well, maybe three. Or one… So writing your own solution isn't much less risky than trusting to a reliable tool vendor. (See The Boy and The Nettles for more thoughts on this.) Now good design practices can help mitigate that risk, but not eliminate it.

That sort of risk is one motivation for Open Source development: if it's Open Source, then you can always fix it yourself if you have to; and there's a chance other people in the community are maintaining it; and you can find support forums online. Sometimes that works; but sometimes Open Source projects get abandoned. And sometimes some good Open Source Version 1 products become Closed Source Version 2 products, once the producers have established a market for them. Nothing wrong with that; but it means you either have to stick with and maintain the old version, or go back to trusting a vendor to stay in business and support a product.

Honestly, while this risk is non-zero, I think it's exaggerated. I'll take a small risk with a really good tool any time. If you do your homework and check reviews on the tool, you can minimize the risk. And unless the tool is core to your business, making your own is a greater risk.

Posted on Saturday, November 15, 2008 5:42 PM Aesop's Fables of Software Development | Back to top

Related Posts on Geeks With Blogs Matching Categories

Comments on this post: The Horse and the Stag

No comments posted yet.
Your comment:
 (will show your gravatar)

Copyright © Martin L. Shoemaker | Powered by: