When are the best tools too expensive?

A while back I was working with a team on a Go project that used Mage as its build system.

I had never used Mage before that, but I quickly came to hate it.

It violated some of the core principles behind the Go language; namely the idea that nothing should be “magic” (I guess given the name, I should have known…). It used a custom sort of inheretence to compose build commands that requried an intimite knowledge of Mage to be able to debug or extend. (For those unfamiliar: Go has no inheretence concept natively.)

The team voted, and almost unanimously agreed to migrate to Makefiles. Make is by no means perfect, but at least it’s simple for simple tasks, and we only cared about simple tasks for this project. It also has the advantage of being nearly ubiquitous, and easy to debug and extend (as long as you aren’t doing anything fancy, anyway).

However, it quickly became apparent that switchting to Makefiles would be fairly disruptive. Since building is central to software delivery, the Mage system had become a key component in everything important our code did, so changing it would have been fairly disruptive. And as the project was using a microservices architecture, with one repo per service, it would have meant doing a the same disruptive change a couple of dozen times or more.

So what did we do?

We stuck with Mage.

Those of us who worked with the build system learned the nitty gritty internals of Mage, so that we could properly debug and extend the system.

While I’m a strong advocate for always using the best tools money can buy, there are times when the non-financial cost of using the best tool simply isn’t worth it.

If you enjoyed this message, subscribe to The Daily Commit to get future messages to your inbox.