When working on internal tools, I often find ourselves talking about quality as a value in itself (an intrinsic value, if you will); both when considering plans, and when communicating with our users (developers, in this case).

Last week I came across a (taxi|cab) sporting a tagline along the lines of "committed to quality". What I realized is that I have no idea what it means for a cab or cab company to be of high quality. What I care about is getting from A to B in reasonable time, for a reasonable price, without anything bad happening (like, say, an accident, or the driver being rude, which is arguably even worse than an accident).

I don't care one bit about the size of the engine, tire pressure, or the color of the toe-nails of the driver. All I care about is having a pleasant experience while getting the results I expect.

So here's a thought: the same applies to developer tools, even internal developer tools. Quality, as in code quality, is only interesting in that it allows us to implement new features and fix bugs faster. What matters in the end is the experience developers have while using our tool - that they get the result they want, that they have a good experience on the way (the tool is "delightful"), and that nothing bad happens.

This of course leads to a more generic and stronger point: developer tools are products. Especially internal tools: they need to create very real value, otherwise it doesn't make sense to work on them as opposed to working directly on the product of the company. Since companies usually have very limited resources for working on internal tools, the trade-off between spending time on refactoring code and spending time on fixing bad UX is extremely pronounced.

In short: internal tools are a product with scarce resources; plan accordingly.