When to Change Tools?

Posted On: 2020-04-06

By Mark

There is something of a paradox to picking a software tool: the better you understand a tool, the better you will be able to know whether it is a good fit for a particular problem. Yet many software tools are designed as turnkey solutions, leaving developers in an awkward place where changing tools means completely abandoning the previous one. Even when the tools themselves are designed to be more modular or independent, transferring data between tools can become an obstacle of its own.

Thus, it is valuable to be skillful at knowing when to stay with a tool, and when to change to a different one. When a friend asked how I approach it, I thought about how tools fight back against their users. When a tool is designed to achieve one goal, and that goal conflicts in some key way with what you are trying to achieve, then it is "fighting" you. Such conflicts can be worked around, but inevitably those situations are ones in which the tool is adding hardship - a clear sign that one should be considering other tools.

Harsh Reality

Yet, after writing out all my thoughts on the matter*, I found myself faced with a fundamental problem: no matter what I say about changing tools when they fight you, it's not what I actually do. Unity has fought me tooth and nail, but I keep fighting back, struggling to make it bend to my will. Even looking over my more mundane tools, like art programs or document editors, it seems I use the ones I am most familiar with, not the ones that are best suited to the task at hand.

Yet, as I think back on those experiences - places where my tools fought me - those were places I doubted their fitness. When Unity fought me over scene serialization, I turned to Godot, to see if its automatic scene serialization would be better. I've looked at Otter and Monogame as well, each on a different time when Unity fought me.

Yet, in the end, I stay with Unity. With nearly a decade in C#, around half that as a hobbyist Unity dev, and over a year full-time working on this one project, Unity represents an enormous sunk cost. Can I really throw all that away over one disagreement?

Softer Reality

Looking at my use of art tools tells a bit of a different story, though. GIMP has long been my art program of choice, but I had quite a while were I relied exclusively on Graphics Gale for pixel artwork*. I've also dabbled in a number of vector art tools, but never quite got to a good comfort level with any of them. At its heart, though, I think using a diversity of art tools is really only possible due to the relative ease of exporting from one and importing into another. Jumping between vector and raster art, for example, represents a significant barrier that makes it difficult to add vector art tools into everyday use.

Final Thoughts

While I would love to say that you should dump tools as soon as they fight you, the reality is much more complex than that. When tools support transferring data smoothly between each other, using a new tool becomes a much smaller commitment. For other applications, most especially game development, that portability is essentially non-existent, and changing tools represents a massive commitment to learning the new tool, hoping that its (as yet) unknown problems won't be as bad as the ones you fled. I suppose that means that, for me personally, Unity is the "devil I know", as the saying goes.