Unexpected Benefits of Building Your Own Tools

Recently I've been thinking a lot about some of the tools I've made, and I have found an insight from game development that I think can apply to the software engineering industry as a whole.

The origin of the insight

I'm working on a hacking simulator, Botnet of Ares and part of the work involves designing and balancing the parameters for the various Exploits that the player can use. For context, these Exploits are kind of equivalent to items in an Role-Playing Game. They have stats similar to "Damage", "Attack Speed", "Mana Cost", except framed in the context of a computer thread performing work - so the rough equivalents in my game would be "Machine Speed", "Loss Wait Time" & the various "Per Machine" costs, respectively.

This used to be done in a spreadsheet, and the process involved copy-pasting ~10 fields every time I wanted to move something into or out of the game.

Spreadsheet editor for Botnet of Ares Exploits, with ~10 user input fields and ~10 descriptive & balance related fields.

At some point I realized that I am spending an eternity staring at spreadsheets and it was just no fun for this sort of task. Furthermore, I was wasting a lot of time copy-pasting things into Godot (the game engine I am using), play-testing, noticing something is wrong, going back to the spreadsheet, editing, copy-pasting again etc. etc. etc.

So I decided to implement my own editor which can save & load directly using the Godot .tscn format. It's super quick & dirty & not optimized at all, but it's already made the process of creating content for the game much faster.

Exploit Editor for Botnet of Ares. Has similar fields to the Spreadsheet editor, but provides much more information and is significantly faster to work with.

All this is is a little editor that lets me input stats for the various exploits, shows a bit of info on the right side about its balance, and then outputs a scene file that can be loaded directly into the game.

What this has made me realize is that speeding up part of a workflow can provide value far beyond the mere time savings: it also unlocks new ways of working that were not possible before. For example, with the Exploit Editor I can go over entire lines of devices and balance them in relation to each other. This used to be incredibly tedious to do with the spreadsheet because of all the tedious copy-pasting required to import from the editor. But now, I can edit dozens of scenes and remain in a state of flow throughout.

The editor has made the creation of these Exploits at least an order of magnitude faster, and has also increased the quality of content I can make by letting me iterate much faster. Not too shabby for ~4 hours of work!

Iteration velocity: the insight from game development

I was motivated to build the Exploit Editor for Botnet of Ares thanks to a common principle in game development: to design a good game, you must iterate through as many versions of the game as you can, keeping the parts that are fun, getting rid of the ones that are not & improving the game at any step. Essentially, the more iterations of the design you can make, the higher quality your game will be - limited, of course, by your budget.

I built the Exploit Editor because I could not iterate through various item designs quickly enough, and as a result I now have many more items in the game, and they are all higher quality than they would be without this tool.

This is a well-known principle in the games development industry - in bigger studios there is often a team dedicated to building & supporting tools & editors for designers & other folks to use. And I think this principle has applications far beyond game development.

Application from work - the chilictl utility

During my day job I have worked on an utility called "chilictl." It allows one to list embedded devices connected to the PC, see basic information about them & flash a new application.

$ ./chilictl list
2020-12-16 12:53:35.897 NOTE:  Cascoda SDK v0.14 Dec 16 2020
Device Found:
        Device: Chili2
        App: mac-dongle
        Version: v0.21-71-g49212790
        Serial No: FBC647CDB300A0DA 
        Path: 0001:0051:00
        Available: Yes
        External Flash Chip Available: Yes
$ ./chilictl flash -s FBC647CDB300A0DA -df "~/sdk-chili2/bin/ldrom_hid.bin"
2020-12-16 12:56:46.510 NOTE:  Cascoda SDK v0.14 Dec 16 2020
Flasher [FBC647CDB300A0DA]: INIT -> REBOOT
Flasher [FBC647CDB300A0DA]: REBOOT -> ERASE
Flasher [FBC647CDB300A0DA]: ERASE -> FLASH
Flasher [FBC647CDB300A0DA]: FLASH -> VERIFY
Flasher [FBC647CDB300A0DA]: VERIFY -> VALIDATE
Flasher [FBC647CDB300A0DA]: VALIDATE -> COMPLETE

All of these things are things you could already do in other ways before the tool was created. For example, you could find the serial number by connecting to the USB debug API & looking for the right printf. Or you could flash devices by digging through your drawer, getting your JLink programmer out, making sure the flimsy 10-pin JTAG cable hasn't snapped a wire internally like the other 5 you've had to throw out this year, opening the correct programming utility & then finally flashing.

You can see where I'm going with this. A single utility was created that removes 90% of the tedium. The tool would have been worth it for this reason alone, but now my colleagues have incorporated it in countless workflows. Here are some examples:

The crucial insight is that none of these applications would have been obvious without being able to flash devices an order of magnitude faster. And chilictl was not designed to be built into these! All of these applications were unlocked once we had experience with the new utility.

Tools don't have to be complicated

One of the highest returns on investment I've had on workflow automation was the script below. It rebuilds an OpenWRT image from scratch with updated dependencies.

#!/bin/sh
./scripts/feeds update -a
./scripts/feeds install -a
make clean
make -j12
# Write logs to file, for debugging
#make -j12 V=sc -k 2>&1 | tee build_log.txt
cmatrix -b

Ive lost count of how many times I ran make without first updating the feed I was working on! The call to cmatrix at the end plays a Matrix inspired stream of green characters the moment the build finishes. This solves the problem of starting the build, working on something else & not noticing that the build has completed even when it was a rather high priority task!

Lets say this script took five minutes to write. If it saves one rebuild, it has already paid for itself four times over. It has saved much more time since. Thanks to this script, debugging certain things that used to take a whole day now can be done in just a few hours.

Conclusions

I think many people could benefit from creating more tools for their own needs. Think of the fraction of your work that you hate the most, and see if there's any way you can remove some of the tedium from it. Even a little bit of automation helps a lot if you are automating a common frustrating task.

And often, you will find that these tools will let you work in new and surprising ways. Ways in which would not have been obvious had you not built the tool in the first place. This leads not just to building your application faster, but building a higher quality application as well thanks to the benefits of iterative development. As the saying goes, quantity has a quality all its own.

tagged Development