Hello everyone! Spring is around the corner. Annual bonuses at large companies are appearing in bank accounts. This must be the month of March.
I am unapologetic for advertising March as “International Replace Your Job” month. When you reach a certain point in your career, there is a fine art to figuring out the right time and place to trade up for your next opportunity. There is a mix of end-of-year bonuses, available opportunities, and quality-of-life issues that everyone needs to balance. I have had a number of conversations with people over the past few years about new opportunities, and what is the opportunity cost of a new role versus what goes into the bank from your current employer. I will probably speak to that some more in the future if it is already not buried deep within my blog.
Today I want to talk about making tools. I think that making tools is very important.
“Good companies make products. Great companies make tools.” I am not sure if this is my wisdom or not. A Google search on the subject yields lots of drills, hammers, saws, and wrenches. I am likely to link some from the Amazons later in the article as a matter of course.
Over my career I have worked with all kinds of software—good software, bad software, new software, and old software. Over twenty years I have observed a few interesting questions that come up when I am in my stupid-or-new phase at a company.
“How long does it take a new developer to be ramped on our stack?”
“How do we put software into production?”
Excellent answers to these questions define a thriving business.
At a recent game company, I noticed that there was an interesting pattern forming during product planning. Because we were doing SAAS (software-as-a-service), we needed to build accompanying tools for our product so product owners could make changes in production.
The bulk of the team would play an unusual game during planning. When asked how long it would take for them to build the web tools necessary for the product to be successful, everyone would attempt to play some bizarro-universe version of “The Price Is Right”. What was the largest estimate they could submit to the planning team without bidding so dramatically that it was clear they were sandbagging? It was a fascinating process to behold. People on this particular game team hated making tools. They wanted to focus on making the game. Each person was doing their very best to make sure they could evade tool development by engaging in a super passive-aggressive sandbagging process, where the losing developer would submit the least outrageous estimate, or alternatively, having made such a mockery of the process with their bid that they earned the task as a punishment for sandbagging too much.
Why did this happen?
To understand, let’s discuss what happens when a new game feature goes live in a SAAS game.
The deep truth for game development is that most of the ideas for feature development are stolen from competitors, or they come from a product owner’s butt. There is always a preconceived notion for what product owners will need to tune, and what players will love.
The funny thing about most of these preconceived notions is that they are often dead wrong.
When a feature goes live, there is usually a need to revisit the tools, add new parameters, and change the business logic in order for the feature to thrive.
A big problem here is that most of the squads on a SAAS game are on a rolling feature development schedule—by the time they find out that the tools need to change, everyone is onto something new.
There is no developer alive who is working on “Shiny New” who wants to be pulled off of their project in order to modify tool features—AKA “Stanky Old”.
I watched this pattern play out month over month with tremendous fascination. After a few iterations of this, I observed that the follow up “we need to change the tools” requests were generally a vicious negotiation process that escalated to leadership, and often resulted in a common concession: Let’s Make a CSV import tool.
A Comma Separated Values (CSV) tool would enable product managers to open up their best friend in software development, Microsoft Excel, tweak a bunch of values, and then save that out to a file to be loaded into production.
At that point it occurred to me that making custom UI tools was a painful exercise for everyone and should be done away with. We should build in CSV importers from the very beginning and let product owners Excel at their work.
Some of this holds true today. “Build CSV import/export” ranks high on my personal backlog for tool development.
While this is a powerful feature to add to a product for a plethora of reasons, it papers over a problem. Many production tools are designed well before their use case is fully understood. Oftentimes, you need to build and ship a product in order to really figure out the best way to use it. The “ship-and-iterate” Agile reader is nodding smugly at this point. Get the code into customers hands and improve as we go.
Figuring out what you need to manage your software is a very hard problem to solve. After a few years of building tools you will find that there are recurring patterns for most business users. You will want data driven import tools, you will want a template for building fast CRUD (Create, Read, Update, Delete) pages, and you will want a small handful of other tools for things like managing users and permissions.
If you are fortunate enough to build successful software products, you will find that building out tools like this will be important to iterate on your product. Creating a toolkit to enable new developers to be successful is also really important. If you can make tool development easy and enjoyable for your development team, you will get some of that “1 + 1 = 3” mathematics that people who go to “Bidness” School are so very fond of.
That’s it. That is the whole post. If you love making software, you should learn to love making tools. Being great at that will enable your organization to ship better stuff faster and give you time to explore hobbies. Like me, about to buy this CLEARLY AMAZON AFFILIATED Cintiq tablet.
See you all next week!
