I disagree. Obsessiveness with small methods means less opportunity to keep your transient state in local variables, meaning you are going to make it object state (use object fields), which would actually <i>increase</i> your side effects.<p>Edit: It occurred to me that there is a case when you need to move state out of the stack to global or instance variables: programming async IO. It is notoriously inconvenient for exactly this reason.
Perhaps I've become an FP zealot, but I just can't agree at all with this author's suggestion. Small methods, "agile", unit testing, and <i>all that</i> are fine and lovely, but none of them approach the kind of safety and composability you get from true FP.
"It’s the closest to side effect free programming you can get in OO."<p>No, you can still have side effect free programming in OO. All of the techniques for programming without using mutable state are language agnostic and should carry over to whatever OO language you are using. You might have problems in languages that lack tail-call optimization, but even that can usually be worked around by using folds.<p>Now, I'm not claiming that it's feasible to make an entire app in (for instance) Java purely functional, but you can definitely build the majority of your app/library/whatever without using mutable state.