ego.istic.org

The title of this post is taken from the traditional spoof DEC missive: “We've got debuggers, one we support and one we use.” The way it is mentioned in that spoof is to be taken as a criticism of the attitude.

The attitude in question is that your customers aren't good enough to use the high-powered tools that the internal developers use. There are two products: one of them is actually useful and functional enough to use for real work; the other is a simplified version for stupid customers, with all the actually useful things taken out. Only the latter of these is supported by the vendor, and probably only the latter is documented. Usually, any queries about the Serious Tool to the vendor meets with blank looks from the support people. They tell you to use the Idiots' Tool instead. Even when you explain that the Idiots' Tool doesn't have the functionality you want, they say that you are obviously doing deep enough things that you should just get by on your own.

This is a reprehensible attitude, or so I used to think. But DEC, as the linked pages indicates, was quite well respected, and I think this dual-track tool-chain is one of the things that contributes to that. A certain company whose interface I use quite frequently does something similar. We've got two API's: one (in C#) we support and one (in C++) we use. Guessing which is which is an exercise for the reader. This way of supplying things to customers does have certain advantages, especially with C# vs. C++ libraries. It's very easy to shoot yourself in the foot with C++, especially in such a way that it looks like the library is at fault. Not supporting it reduces a huge support burden from people who've written buggy applications because they think they know what they're doing. Using it internally is good because it allows a small, strongly vetted community of competent developers to write high-performance applications. For the unwashed masses, the C# library is fine, it's easy to use, and it seems to be what people want. (.NET seems to have quite a lot of uptake in what they call the enterprise market.)

The other advantage of having a hard-to-use library that is heavily used internally is that we find all the bugs and the customers don't. The few people who do actually get to use the C++ interface, on the understanding that they have to make it work on their own, thus find it to be robust and powerful, which is exactly what they want. Such documentation as there is, being intended for internal use rather than customers with indeterminate knowledge of programming, tells you what you need to know in concise language. Both the vendor and the customer win.

That's not to say it's all good. It is easy for the internal-only tool to become completely undocumented, because everyone who uses it has access to the source, and buggy, because everyone who uses it knows how to avoid triggering the bugs. Likewise, it's easy for the shipped-only tool to become virtually unmaintained, because the people who are annoyed by bugs and NYI's are not the people who can fix them. Anyone who has been annoyed at having to use the Windows shell to create symlinks rather than using a graphical interface, or at chasing through several “Advanced Options” buttons to get at the setting they really want, knows how bad it can get. Like any innovation, dual-track tool-chains can be used for good or evil. But with application of sufficient laziness, impatience, and hubris, it is a powerful way to limit how much your stupid users can shoot themselves in the foot while ensuring that the experts can still do exactly what they want.