But does it help you ship?
Whenever I’m not sure whether I’m spending my time on the right thing I ask myself: does it help me ship?
If what I consider working on is not the thing we want to ship itself, but lies in the vast grey area of software projects where I could write code all day long without the user ever noticing, this question helps me decide whether to drop it or invest some time in it.
Let me illustrate.
One imaginary Friday afternoon I notice that we have a few // TODO comments in our
codebase. Hmm, I could create a bot that looks for those comments whenever a new
commit is pushed. It could use git blame to see who the author is and create a
ticket assigned to them, saying that they should fix their TODO in line X in
file Y, please. And, cherry on top, when a pull request that touches a TODO is
opened, the bot would mark the corresponding ticket as work-in-progress. And
when the pull request is merged, the bot closes the ticket. And when a pull
request merely changes the TODO: into a TODO(poorsoul): then it assigns the
ticket to poorsoul.
Sounds pretty good, right? Turn those TODOs into tickets and never lose a TODO again.
The problem is: it’s not free. It looks like it is, because the code is quickly written and it runs as a GitHub action we don’t have to pay for, but it’s not.
It’s another process, another tool, another automated piece in our machinery. Another thing that needs to be fixed when it ultimately breaks down, another bit of automation that works 99% of the time, but starts making funny noises when you slip into the 1% and, say, moved a TODO down five lines by accident and don’t want the bot to close and re-open tickets, kicking off another wave of notifications.
That’s the actual cost of adding that bot.
The question is do we want to pay it? Does it help me ship? Does it help me ship more? Or does it help me ship faster, or with less friction, more safely?
If our imaginary codebase has more TODOs than test cases, for example, and these TODOs are holding us back from shipping because we can’t make a change without having to ask colleagues what this TODO we just discovered means, then it might be a good idea to add the bot. Even if we don’t intend to fix all of the TODOs, but only to finally get an overview and a peek at hidden part of the iceberg. It helps us ship.
If the code contains more than one TODO: make sure this works and we can’t
ship because changing the code is playing a game of Russian roulette, where
every change could kick off an avalanche of bugs, then yes, this bot would
probably help us ship.
But what if we’re not held back by TODOs? What if we have a total of 18 of them, and 12 of those have been in the codebase longer than you and I have been at the company, and, generally speaking, our codebase is in an okay state — is the cost worth it?
If what’s holding you back from shipping is, say, getting more customer input, or a brittle release process, or flaky monitoring, or missing tests, then all the bot does is to add noise. It doesn’t help you ship.