Does Yagni Interrupt Flow

I also sympathise with the (opposing) view that it is easier to add features to an object at the same time that you are adding other features to the object. This is partly because it takes my brain a little while to get up to speed on a module. This is especially true if it was written by someone else.

If the code is well-written, it won't take long to come up to speed. (If it is not well-written, it needs refactoring, not enhancement.) If you just can't resist the idea, it's usually best to leave yourself a comment and get back to doing the job you came here to do. --RonJeffries

Any time at all is an interruption to the task you were working before. Programming requires long stretches of concentration; it's harder when you have continual interruptions.

We would suggest that doing an extension that isn't called for is the real interruption: when we do that we are interrupting our actual work with a message from the future ... a future that may never occur ... and certainly we have enough to do today.

Another way to approach the above problem posted above is to avoid programming in such a way that requires long stretches of concentration. Careful application of refactoring does exactly that. By breaking a long task into a series of shorter ones (and by shorter, I typically strive of 30-60 seconds) one eliminates the root cause. For what it's worth, I know from whence I speak; I used to be one of those programmers who sat with headphones on for long stretches desperately trying to juggle too many balls at once. My stress level is dramatically reduced when I work in small steps. -- GeoffSobering

A possibly related question: WhoReallyDoesRefactoring ?

My comment was partly motivated by some of the discussion on MethodsShouldBePublic, around about where RonJeffries says:

I would not, however, want the world to stop until I fixed it.

I agree, but why? Why not stop the world, if not because it breaks flow? -- DaveHarris

I always keep a card beside my computer with a to do list on it. When a subtask comes up, I discuss with my partner whether to do it now or later. After we are done with a programming episode, we discuss whether we managed our interruptions well. After a month or so, we do a pretty good job. -- KentBeck

Moved from YouArentGonnaNeedIt

Does anyone else find that YouArentGonnaNeedIt can interfere with flow? You'll be working on one thing, and need some method on another thing and that method won't exist. So you have to switch tasks, implement some UnitTests and the method itself, then switch back to the original task. I find this task switching can break flow. Especially if the second task itself triggers subtasks. -- DaveHarris

Our experience is just the reverse: we just flow over there and implement the method. It gets to feel very rhythmic and regular. I've never experienced such productive and long flow periods in other languages. Generally the method doesn't need its own UnitTest, since our original task will test it. It helps, in Smalltalk, that you can just stack up the browser windows, then unstack them when the subtask is done. That manages the stack for you. In a less friendly system such as I'm used to in C, Java etc, that's not so natural.

There is also, I suppose, a risk that in the effort to maintain flow on the original task, one would skip needed UnitTests on the other class. I haven't detected that here, but I wasn't looking for it either. -- RonJeffries.

I don't really notice it breaking up flow... I implement what I need to support the task at hand, and what I need to ensure the code I write works (not necessarily in that order). The goal is the same. How is this different from having to implement a method on another class that doesn't exist because nobody thought of it? I've rarely been so lucky that all the support I needed for some new thing already existed in the system in a form that I could readily use - that's one of the ideas behind YouArentGonnaNeedIt, right? -- BillJamison

I use two approaches to this. The first is to use the stack of programming environment windows as a short-term to-do stack. I try "implementors", see that something needs to change, change it right there, close the windows, then I'm right back in the context that spawned the subtask, with all the selections etc right there to remind me what I was doing. The second is that I always keep a private to do list on a card. When a subtask comes up, I either deal with it, add it to the card, or make a card for it and add it to the task board. -- KentBeck

Flow vs. productivity

Yes, YAGNI interrupts flow. Flow is where you are guided by the code: you do what the code wants you to do--you and the code are single, organically fused being whose will is elegance. Flow can lead you to tune up the interface between the whosit and the whatchit classes to 10,000 times greater elegance than matters to the people who are paying you.

YAGNI does not serve art. It serves the people who pay you. It leads you to turn off flow and consciously decide to make wise trade-offs on your customer's behalf. That's why you're paid like a professional and not like a poet.

It's not so bad with pairing

The interruption to the pleasure of programming that arises from flow doesn't seem so bad when pairing. It's painful when I'm coding solo and have to keep forcing myself out of flow. When pairing, you know when driving that your partner will pull you out of flow if you go too far. That means you can fall into flow completely without inhibition.

This only works, though, when your partner is not actively opposing YAGNI in favor of premature generalization and the other temptations of flow. I have actually paired with people who'd yell, "You're interrupting my flow!" when you tried to remind them that they're violating YAGNI after they spent 2 hours without getting a test to pass. See HowToPissOffYourPair.

Perhaps the two of you shouldn't have been pairing at that time. If you spent 2 hours without a green bar, you were plainly spiking - and you should SpikeAlone.