TODO: Am I trying to solve a non-existing problem?
I have been building Catana for a few months now. It’s a developer tool to help support and enhance TODO comments written in a codebase.
I launched a closed beta two months ago.
I’m starting to doubt whether what I’m building solves a problem developers care about. I would really appreciate your opinion!
Short intro to Catana
In a few words, Catana helps organizations and projects surface, assign, and remember to address TODOs. I built it as a SaaS, and it's installable with a couple of clicks.
Why I decided to build it
The idea emerged a few years ago when I worked at my previous company. The core project was quite large, and the number of developers working on it too (400-500).
The number of forgotten TODO: Fix this/Do this/Blabla kept increasing, and there was clearly a problem with accountability and visibility.
To solve this problem, I took the initiative to create a small tool to support their usage by adding convention and automation to remind TODO authors. The solution I built was simple but useful enough and was well received.
Worth noting that banning TODOs with a linter was excluded as TODO is a helpful tool in a developer’s arsenal (when used correctly and sparingly).
Fast forward to 2022, and here I am rebuilding it from scratch to make it a product with more features, easier installation, and supporting 200+ programming languages.
The desillusion
Before building Catana, I didn’t do any user interviews except from my group of developer friends.
From my previous experience, I was convinced that developers would find it helpful. A quick “TODO” search on GitHub that returned millions of results comforted me with the idea that TODOs were popular, but there was no good support around them.
Arlight, so Catana is built, and I want to validate the core functionalities to ensure there are no major bugs. My target was open-source projects (mainly because those don’t have data leaks concerns), but I hit a wall.
After some back and forth with a few project maintainers, I realize that being reminded about TODOs is not something they want or need. It creates unnecessary noise.
Same feedback regarding the convention Catana adds around TODOs (adding an assignee and a trigger to tell Catana when it should remind its author).
A remark that often came back was “adding TODO just in case”.
Based on this feedback, I ultimately came up with an analogy: The empty-pocket box.
We all have that box at the entrance of our home where we put pretty much everything useless, batteries (maybe empty ¯\(ツ)/¯ ), coins from countries we can't remember, used bus tickets. We keep them in that box "Just in case. It may be useful someday”.
So here are my questions for you:
- Are TODOs something you care about (your own and the ones from others)?
- Have you encountered a TODO in a project and hoped you had more context?
- When you write a TODO, is it to be a good citizen, but you don’t have much expectation to resolve it, or would you value being reminded at a time or condition of your choice?
- What’s in your empty-pocket box :D?
Thanks!
I like it!
In a simpler fashion, many IDEs will have some sort of TODO / task integration to at least list the TODOs/XXX/etc comments, but it's usually too rudimentary, because we either:
We'll often to do something like: "TODO: rewrite this when JIRA-XXX is complete", but there is no deep linking. And if we see TODOs in code review, they'll get flagged to be dealt with in some way. But again, there is no loop back when that task is finished. Or that version is released, etc. There is no actionable if we don't remember.
This would be useful in my org (small eng team with 10 apps), if:
Essentially you are sitting on future/potential tasks or before they are concrete enough to go into a tracking tool. That sort of shifts this towards more project management rather than development stuff, though. That's still relevant to developers if they have autonomy over their code and technical debt tracking, though!
To add one more point: we have nearly infinite "we should do this thing IF ____" sort of tasks / TODOs in our head all the time. Tracking those is really valuable. We try to catch those in our heads as we work on things, but there's never a larger list. Some will never get resolved, and that's okay.
Thanks Adrian, this is a super helpful feedback!
Absolutely! As you mentioned those integrations are limited but still useful. I originally introduced a different syntax, but I was advised to stick with "TODO" in order to not break existing tools/IDE, which I think was a great idea.
👍 Noted!
That's interesting! Do you have a medium in mind to display the recorded TODOs? Would you find it useful to have some sort of VSCode/Editor extensions that would display TODOs across your project in a nicer way than doing a plain grep?
That's really helpful to know. I kind of deduct that being reminded very occasionally would help, like a reminder once every X months (where X could even be configurable).
That's a really great point. I also told myself recently that Catana is on the blurry line of developer tooling vs project management.
I think I'm frustrated about issue trackers (Jira, GitHub ...) that are too static (it "just" allows you to write some text and attach files) but don't have integration to follow the lifecycle of the project. A basic example would be creating an issue regarding a specific line of code, if that line gets deleted, the issue doesn't apply and should be closed.
Thanks for mentioning that anyway ❤️. I'll spend some time rethinking what market Catana fits in, and whether there is a spot for it!
The easiest I can think of are: 1) GitHub badges, so we can at least easily navigate to them similar to other code tools, and 2) API which can lead into the other stuff (in editor, slackbot, etc.)
Many teams will do this on some schedule (sprint planning, or more general backlog refining for tech debt). I'd either want a dashboard I can open for that session, or be reminded ahead of time and glance at it each time.
Good luck! I'll keep tabs on it.
Thanks for your feedback!
👍 Sounds good. For small technical issues (i.e. rename a variable, dig into a flaky test ...) how do you surface that with other devs in your team?
I suppose they have to run into the ticket to know the piece of code they look at has an issue associated.
May I ask, what's your workflow to remember about those? Do you regularly check your issue tracker?
Would you find it helpful to be able to comment on the issue something along the line:
"remind me on January 1st", "remind me when Issue #154 is closed" or even "remind me when yarn is released to version x.x"
and have a bot remind you?
yes that is the source of truth. dig into flakey test would go into issue tracker and whoever has time will dig into it. Tasks also have priority associated with them so if flakey test is not on priority it will just get pushed into backlog and whenever someone has time or new intern comes these low priority issues will be dealt with.
My workflow is different now because i work for myself. When i used to work in teams there were program managers, blocked teams pinging you left and right escalations from customers etc. that i did not had to do any prioritization whatever was on priority automatically bubbled up. There were weekly/monthly/quarterly sync ups where we used to go over lower priority issues to check if something can be worked on depending on bandwidth.
yes that can be useful but its vitamin not pain killer in my opinion. Having said that i am consistently wrong about my predictions ;-) so may be it is a pain killer just not for me.