All Tools Suck: More Explanation

In addition to all the reasons I outline in the first post explaining why all tools suck, it's also important to understand what my normal relationship to most tools is.

I am not a typical user by almost any measure. That is, I'm not interacting with tools as a user of those tools trying to accomplish some task that those tools have been designed to support. Rather, I am interacting with those tools as an evaluator and integrator trying to make them work with other tools, trying to make them do what my clients want them to do, or extending their built-in functionality to do things they don't do out of the box.

This means that I rarely, if ever, care about what things the tools get right--if a tool gets it right then I don't care because I don't have to worry about the stuff that works, only the stuff that doesn't work.

This is a recipe for frustration and bitterness, because tools, no matter how good or how appropriate for task never do everything you want them to do, are never without bugs or API holes or silly user interface things, but all I see, all day, every day, is what doesn't work, what impedes my ability to satisfy my client's requirements [It's also important to know that Innodata Isogen is typically only hired to do stuff that is hard or that hasn't really been done before, so we're rarely doing workaday, tried and true stuff, but pushing the envelope, whatever it happens to be that day.]

It would be a little like being a taxi driver who only picked up mean crazy people--you'd get a very skewed view of humanity. It's sort of like that.

So that makes me pissy and bitter but nevertheless I still have to make these things work so I have no choice but to continue beating my head against these things day in and day out. Just like the taxi driver, I still have to carry the fares or I don't eat.

It also means that most of my interaction with support personnel and tool developers is about what's wrong with their tool, not what's right with it, which is unfortunate. SoftQuad, back when they were an independent company, the makers of what was Author/Editor and what became XMetal (now owned by Blast Radius) had a person specifically assigned to handle my issue reports (it wasn't their entire job, of course, but it did take a good bit of their time from time to time). I try to be constructive when I submit issue reports against tools, providing sample data, clear descriptions of how the problem occurred, what the customer requirements were, and so on, but I'm sure that doesn't take the sting out of it.

So to all those tool developers that I have pounded with issue reports and feature requests, know that just being in a position to get those reports means, in most cases, that your software is sufficiently superior or compelling to warrant my attention at all. That is, I only spend time reporting problems with software that doesn't suck nearly as much. [Most tools I evaluate fail to meet my requirements within the first 5 minutes of my using them. This makes tool evaluation easier but doesn't speak well of software engineers generally.] Cold comfort I know, but it's just not practical to send the occasional "hey, your software hasn't crashed or impeded my integration and extension attempts at all for a whole month--good job guys, keep it up!". Not going to happen, at least not normally.

Maybe I can help to change this situation a little bit here by singling out for praise those tools that I do in fact find to not be particularly sucky, as I've already done. Of course, this can't just be a love fest....