One of the things I really enjoy about the software development teams I’ve worked with is their relentless focus on improving their overall productivity – producing more business value in less time and with less cost each every iteration. It’s largely this drive for productivity that drives developers to focus on quality – buggy code is hard to maintain and delivers little or no business value. Similarly it makes developers really care about the tools they use – the programming language, the OS, the IDE or editor, continuous integration, source control and all the other tools or systems they have to work with. When it comes to tools, nothing is ever good enough and we always want more. So long as that desire for perfection is balanced by careful, realistic prioritization it’s a fantastic thing to have in a team.

However, there’s one very common blind spot in this drive for perfection – in the tools we write for ourselves. It’s quite common for a team to decide that a third party tool simply isn’t good enough for them and is hampering their productivity so they should write their own, better version. The new tool quickly comes together and starts showing how much better it is than the old tool in the identified areas of weakness and everything is wonderful and rosy. Except of course, that it isn’t.

What teams generally miss is all the ways that the original tool was wonderful and polished, and the new tool is seriously lacking. For some reason we have to be a lot more pragmatic about the tools we build than about the tools we buy. There’s no good reason for this, our homegrown tools should be not just a little better, but a lot better, indisputably better than what they replace. If they aren’t then we’ve wasted a lot of precious time developing a tool that would have been better invested elsewhere. Solving the problems of the old tool is not a productivity gain if you fail to replicate the good things about it as well.

The common attribute among the best tools, that really provide measurable productivity boosts, is a relentless attention to detail. UI is the most common area that people think of when sweating the details, but this isn’t about having a perfect looking UI – it’s about making it quick and easy to use the tool for what it’s supposed to do. The real purpose, not just the first purpose you think of. For example, a continuous integration server isn’t about regularly running builds – it’s about making it easy to see when and why something broke in the software.

Similarly a build tool isn’t just about building your software. It’s also about creating static code analysis reports, running unit tests and probably interacting with a number of other systems – it may even start and stop the system during development. The scope is generally so much wider than just the basics of compiling code and dumping it into a JAR or ZIP file. That extra scope affects the trade-offs you should make in choosing your build tool. Maybe it’s not so important to make it build a trivial project just using all default settings. Maybe the scope is now so broad that building your own tool is more work than it could possibly be of benefit.

Ultimately, developers like to believe that any problem is quick and easy to solve. It’s the details that kill though – either because they’re missing and the tool doesn’t deliver productivity improvements or because they dramatically increase the effort required to build the tool, eliminating any potential return on investment. So when you’re next considering building your own version of some tool, first stop and think about all the little details that are required and make sure you really sweat them if you still decide to go forward. You may suddenly find you’re better off getting involved with the development of an existing tool and improving it rather than starting again from scratch.