It's just an Internal Tool

Some developers (often the most effective ones) are tool makers - they see something that happens repeatedly and instead of tediously doing the same task over and over again, they create a tool to make the job easier and more reliable.

These tools might be used to generate some repetitive code, to update files for an automated build, to test an integration point, for deployment into staging or production, as a health check or something else entirely.

Unfortunately, there’s seldom time allocated for writing these tools. I’ve known some (mostly non-developers) who actively object to this, arguing that the tools are a waste of time better spent elsewhere - that it is better to do the job entirely by hand every time than to craft a tool to make it easier (or automated).

As a consequence of the time pressure, all too often these tools are slapped together with little error handling or forethought for the future.

“It’s just an internal tool” the developers tell themselves. It’s not really important. We can take some shortcuts.

And so the tool is thrown together with haste, without unit tests, or code reviews, or source control, or automated builds, or a formal design or any documentation - without any of the usual process we normally associate with important code.

Unsurprisingly, the tool is usually a success and becomes essential to smooth operation. The tool fades into the background, faithfully doing exactly what it was intended to do. Sometimes even the original author forgets that it’s there. The code is generated, builds are successful, integration tests pass, deployments work like clockwork, the health of the system is checked on time, every time; the tool works.

Until one fateful day when it stops. No warning, no premonition of doom. It’s dead.

Hopefully, the original developer is still available. If you’re really lucky, she might even remember what the tool does, how it works, and where to find the source code.

More likely, the original developer has moved on, nobody on the current team has ever heard of the tool before, they don’t know how it works and the source code was last seen on a USB stick that was handed the CTOs prior executive assistant.

Creating little tools to streamline the development process can deliver an extraordinary amount of value. It’s also a lot of fun to sometimes throw off the usual constraints and to hack together a prototype to see if something can be done.

I freely confess that I’m rather partial to tool creation myself.

But when the tool starts to become important - when the regular processes of the team start to become critically dependent on the tool - the time for playing around must come to an end.

Unit tests, code reviews, source control, automated builds, formal designs, and documentation: we do these things for production code because we care about the quality and maintainability of the end result. Each of these practices has been shown to be worthwhile in their own right because they help the team deliver value.

When a custom tool becomes important, the quality, maintainability, and value of that tool is also important.

Don’t take shortcuts.