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.


blog comments powered by Disqus
Next Post
Null arguments are evil  14 Aug 2016
Prior Post
Don't work too hard  30 Jul 2016
Related Posts
Using Constructors  27 Feb 2023
An Inconvenient API  18 Feb 2023
Method Archetypes  11 Sep 2022
A bash puzzle, solved  02 Jul 2022
A bash puzzle  25 Jun 2022
Improve your troubleshooting by aggregating errors  11 Jun 2022
Improve your troubleshooting by wrapping errors  28 May 2022
Keep your promises  14 May 2022
When are you done?  18 Apr 2022
Fixing GitHub Authentication  28 Nov 2021
August 2016