Continuous everywhere

There's a difficult tradeoff when trying to shorten a feedback loop: if you take less time to do something, won't it be less good?

It's intuitively obvious that there's a tradeoff between time and quality: to make something good takes more time than making it mediocre. But there's a hidden "something" term in there that gives us an extra dimension to work with. A more complicated thing also takes more time than something less complicated. Perhaps a better way of thinking about it, then, is as a time-quality-scope tradeoff. I've come to think lately that the correct answer is to minimise that scope as much as possible.

Put another way, imagine you have a graph of your progress over time. When you're in the middle of working on something but not done yet, you can visualise it as a gap in that graph. When you finish, the progress goes up in one big jump. I think of scope, in this context, as that gap: the length of time where your progress function is undefined. If someone asks "how's the project going?" you don't really know the answer. And trying to estimate when you'll be finished halfway through a gap is basically impossible.

But you can decrease the size of the gaps in that function by just defining "done" differently. Maybe if you are clever about it, you can have twice as many done points while still achieving the same progress over time. The undefined gaps will shrink, you'll have better and more accurate information, and be able to make decisions more quickly.

It's interesting to consider the ultimate extreme of this philosophy: what if you could get to a point where there are no gaps, and your progress is defined on every time-scale? It would mean no git, no deployment system, no edit/save cycle: everything you do is immediately put into production. It would mean a keystroke is a function is a module is a project. It would mean your progress function is continuous everywhere.