3 ms·
" The only way to know for sure that "this is how its going to turn out" is to actually be in the future." But then what kind of "time resolution" do you use f
by saganus 11y ago
" The only way to know for sure that "this is how its going to turn out" is to actually be in the future."
But then what kind of "time resolution" do you use for "in the future"?
I mean, of course if you talk about weeks ahead, then yes, why should I plan for something that I may or may not need need in 4 weeks?
What is the cutoff then? Next week? Tomorrow? In an hour? 10 minutes?
After 34 years of experience, you have fine-tuned this. But there IS a line, right? Maybe not fixed, but there should be one, otherwise you won't do anything unless it's needed like right this nanosecond.
Reductio ad absurdum of course, but I'm curious how do you know where to draw the line?.
- lowbloodsugar 11y agoWe do TDD. The cut-off line is "this test". Anything more than fixing "this test" is waste. We fix "this test" and write another test. Fix it. Maybe refactor. Repeat. So not next month, next week. More like "next 30 seconds". Even if we are scheduled to do the next feature right after this feature, we still wouldn't start writing a unified solution. We'd write a test for A, then fix it, then write another test for A, and then fix that, and keep going until A was done and now we're writing a test for B. That said, if we really don't know what we're doing then we spike. Then we throw it away and rewrite it with TDD. Sounds mental, right?
- saganus 11y agoIt might sound mental, but if it works better than the alternatives... then how mental is it actually? Thanks for the explanation. It's actually something I will try. I can't hurt to learn new things, can it?