Yes!!! This is exactly what I've been trying to say (evidently unsuccessfully). I guess I'll have to add it to my book—it will take a full chapter.
---
RT @LaVloZ
@tPl0ch @allenholub @davidfgonzalezc I think Allen wants to say that TODO is a symptom and root cause is that try to not anticipate things, if you need it now, it’s gonna be a failing test, if you don’t need it now, no need of a todo nor a failing test
https://twitter.com/LaVloZ/status/1595322831771996160
Merrill Mimyaralem on Twitter

“@tPl0ch @allenholub @davidfgonzalezc I think Allen wants to say that TODO is a symptom and root cause is that try to not anticipate things, if you need it now, it’s gonna be a failing test, if you don’t need it now, no need of a todo nor a failing test”

Twitter
@allenholub do or do not do, there is no ToDo.
@allenholub how would you handle a case like this?: A startup is signing up early users. Half the potential users need X before service is usable for them. The overall system needs improvements before it’s usable for feature A. What about a TODO near feature A that says “Feature X will probably go here?” Or putting so much as a sticky note or something as a reminder to oneself that “hey, feature X is important for getting a bunch of new clients, do it once A is in usable condition.”
@jarrett
The problem is that, once they get some software in their hands, they may change their mind about A, or need to modify what A is. More to the point, if the initial thing is selling well, you might not want to add A for business reasons. There are just too many unknowns, and if you leave TODOs, the code will get cluttered with things you'll never act on. Somebody who comes along later will have no idea what to do with that and may end up actually building A tho nobody wants it anymore.
@allenholub that largely makes sense. In this case I’m not concerned about the need for both features in question. It’s a necessary feature unless for some reason we decide not to do business with clients who pay their contractors by the hour (we have by-day now). Meaning: chances are as close to zero as they can be. How do you handle a list of things you think will add value? Where do you record that besides your brain? I get the point about code clutter.
@jarrett
I learn what to build next by building (and releasing, and getting feedback on) the current thing. I have no idea what's important in the future. Neither do my customers until they get working software in their hands and use it. I don't bother keeping a list.
@allenholub I can’t imagine a case where you only have one thing in mind that you’d like to test to see if it’s a value-add.
@jarrett
I have a conversation with my customers and ask them. I also ask how important it is relative to the thing I'm working on now. A small backlog (say two or three weeks' work, max) might be useful, but even that will have to change as you learn.
@allenholub, that’s fair. If a customer says “I would like to be able to X, Y, and Z,” I would want a way to reason about those options and even track their possible value while attempting to deliver them. As far as backlog length, that seems a little arbitrary, but I definitely prefer mine to be a few days at most, and constantly evaluating the accuracy of each item. Only exception is my weekend projects that must go at slower pace.
@allenholub you mentioned failing tests instead of to-dos. Would you ship the failing test to main, or is that a prompt to do the to-do if you can write the test? There is value in having only passing tests in main.
@cpb
No. I would never ship anything that had failing tests in it. The whole point is to make it impossible to push until you make the test green. It's an enforced to-do, but it's also a TDD test, so serves as an executable specification for what you need to write. Way better than a note to yourself, IMO.