I have often said, “Good teams build products. Great teams build tools.” This has become a part of me over decades of shipping software, both good and bad. The best software I have ever shipped has included many tools for operators and intermediate users.
Over those two decades, I have also encountered a few moments of regret. One of the most frequent regrets occurred when I wished I had access to libraries and tools I had developed elsewhere. If I built a nice kernel-level memory management library in C, why shouldn’t I be able to use that elsewhere if the two companies are not competitors?
I had to throw in that last question because I am sure every armchair software developer was halfway out of their chair to demand “whaddabout competitor?!” Checkmate, dear reader. I am way ahead of you.
Setting aside the competitor issue for the moment, I just imagine needing to call a plumber or an interior decorator, and while I require their specialized knowledge and services, I do not run out and buy them an entirely new set of tools to do my job.
I am reducing this absurdity on purpose. I have not felt this particular type of regret in a while because part of what I have done over the past several years is build some software as a consultant, where I changed the underlying assumption about what I have built from a work-for-hire basis to that of a licensing model.
Part of the reason I did this was to give a steep discount to some customers who were not well-financed. Finding cheap product market fit is attractive, and I priced these projects accordingly. The result was that I built a gigantic pile of libraries for several companies, which I now own.
I have gone through these repositories a few times over the years. Some of the time I cackle and imagine I have a gigantic trove of riches. We all know this is fiction. My dragon hoard of software is not a pile of golden coins and gemstones. It is essentially a collection of half-eaten sandwiches and discarded pieces of lumber.
However, I intermittently have a library for timestamp management, database access, authentication, or similar core technology that enables me to build something swiftly.
I think there is a case to be made for software developers to build and maintain their own tools over the years. I can appreciate the IT department manager developing sweats and anxiety at an army of developers showing up with their personal laptops, fully configured to work, with access to their own code libraries. After all, a good chunk of software projects these days start with a pile of npm install instructions or similar that fetches open-source libraries from a billion places.
I exaggerate slightly and with good reason. In the era of the LLM, I can envision developers who have trained up their own AI to solve specialized problems for them. Does this not enable them to do their jobs more effectively?
I feel like I have to stop here. The world is not ready for this flavor of crazy. The IT department of Giant Mega Software Concern can stand down and move the minute hand of their doomsday clock back from midnight.
I wanted to make sure this was written down somewhere, so when this becomes normal in five, six, or even ten years, I can send links to the young peoples and leap up from my chair, pointing and screaming furiously, “See? SEE?”
I do believe a day will come when it will be normal for people to BYOT (Bring Your Own Tools) to work.
See you all next week!
