All Tools Suck
The motto of this blog (and my professional life) is "all tools suck (some suck less than others)"
That's a pretty harsh statement. After all there's lots of useful software out there (and a lot more heineous piles of crap, but that's just the human condition).
So what do I really mean by "all tools suck"?
A better question might be "what makes a tool a good tool?" The trite answer is "if it meets requirements" but in fact this is the only really useful answer--the key is defining your requirments clearly. If one of your requirements is "doesn't crash all the time" then you've just eliminated a huge swath of tools. If another one is "doesn't take proprietary ownership of my data" then you've eliminated a whole other swath.
My problem, and in fact the problem of anyone who has chosen to use standards for their data in order to get the value that standards provide because they are standard (and not, for example, simply because that's the format the tool you like happens to use), is that standards are explicitly statements of requirement and generally very demanding statements of requirement.
For example, the XSL Formatting Objects (XSL-FO) recommendation, the standard I've worked most closely with the last few years, defines a very sophisticated mechanism for doing automatic composition of printable pages. As such it defines lots of requirements for what XSL-FO should and should not do.
The rub is that for any non-trivial standard few tools will completely satisfy the requirements inherent in that standard, whether it's failure to correctly implement a required feature or just not implementing an optional, but useful, feature.
Therefore, any tool that doesn't fully implement the standard at hand inherently sucks, by definition, because it doesn't meet requirements.
Of course, a given user of the standard may not require all the things the standard requires (that's why most standards have optional features), in which case, any tool that implements those features the user does require and otherwise meets the user's requirements (reliability, performance, cost, etc.) doesn't suck for that user.
But I'm an integrator. That means the set of requirements I care about is the union of all the requirements of my clients and prospects which, since I don't always know what my clients' and prospects' requirements are, is easiest to define as "everything the standard does that isn't prima facia useless".
Plus I make a point of trying to explore the practical boundaries of standards and their supporting technologies, so I tend to try to do things that aren't workaday requirements (but that would still be useful in real use cases).
As most engineers implementing tools are focused either on the requirements they understand or what the marketing department tells them is important or the features they can quickly implement, they tend not to focus on the edge cases. This is just how software development works. It's the very rare engineer who has the time, inclination, and luxury of implementing a standard completely just for the sake of completeness. In fact I'm not sure it's ever happened, at least not within the XML family of standards (the Saxon family of XSLT implementations may be the exception here--Mike Kay is one wicked mofo when it comes to standards implementation and software engineering).
So this means that my starting point when coming to a new tool that purports to support some set of standards is that it fails to support some set of requirements that I have (because it doesn't implement the whole standard [because no tool ever supports the whole standard]). So right off it's at a serious disadvantage. Then it still has to satisfy all the other requirements that any piece of useful software has to satisfy: cost, performance, correct operation, ease of use, ease of integration, etc. These requirements, by themselves are hard enough for most software to satisfy (because most software just isn't engineered that well so, on average, most tools you encounter will be pretty weak, just by the law of averages).
So to review:
- By definition, all tools will fail to meet all the requirements inherent in the standards they claim to support to one degree or another, and
- Most tools are buggy, slow, bloated examples of poor software engineering
It is clear that:
- All tools suck, to one degree or another
The degree to which a tool doesn't suck is then a function of two factors:
- The number of requirements in the standard it does support and the value of those requirements to the likely users of the tools (implementing parts of standards that nobody wants or uses or should use doesn't reduce your suckiness score). [For example, the XSL-FO specification includes a bunch of features for aural presentation of rendered documents. These features are essentially useless for print applications so few, if any, FO implementations support them. That does not count against those implementations because the features are not useful to most users of XSL-FO. However, failing to support a very useful feature like block-containers does count against you.]
- The overall software engineering quality with regard to performance, buginess, value (price relative to features provided), support, documentation, ease of integration, and so on.
For most purposes I give these two factors roughly equal weight, although for most work I give engineering quality somewhat greater weight assuming that the critical features of the standard are otherwise implemented. But sometimes you can tolerate a slower or buggyier or more bloated tool because it implements more critical features.
Finally, as an integrator I don't care just about the raw functionality of the tool but about its features that support integration, such as APIs, command-line options, packaging as plug-ins, platform support, documentation for APIs, and so on. Many tools that are otherwise quite strong often fall down here because this is stuff that relatively few users of the tool care about. So it tends to get to no love (I'm talking to you, Documentum).
So on top of the usual frustrations with poor, incomplete, and incorrect implementation of standards and typically buggy and poorly-supported programs, add my frustration with trying to integrate these tools with other similarly joyful tools and you can see that my job is a recipe for bitterness and pain.
Oh yeah, and one more thing: I am freakin' Eliot Kimber! I've been doing this more years than most of you snot nosed kids with your IDEs and your AJAX hacks and your iPods have been alive so don't be telling me that my requirements are somehow less compelling than what you've figured out by reading XML for Dummies! Listen to me: implement the features I want or your software will be forever cursed! You have been warned!
Now do you understand why all tools suck?