continuous-refactoring-hell.txt

This is a litte muse on "continuous refactoring" a la Martin Fowler,
 what I've seen as typical OO in an enterprise setting, and the yawning
 gulf between them.

So there are a lot of appealing refactoring patterns like "first make
 the change easy, then make the easy change" and so on. These often
 seem to be out of reach for developers in the field, even those who
 are aware of these Best Practices and want to implement them, mostly
 because "make the change easy" seems like a daunting amount of work.
 Then you get into the typical antipatterns of "asking your manager if
 you can be allowed to refactor" and "doing it the quick and dirty way
 to get the ticket out this sprint, we'll come back and clean it up in
 the glorious magical Later When We Have Time". And in short order your
 codebase is a pile of shit.

Wat do?

I think part of the problem is lack of practice - you can hear about
 these techniques all the time, and intellectually buy into the idea
 that they're great, but until you've done it a few times you're going
 to have to slow down and think about it as you work. Even if that's
 not a net slowdown overall, it'll _feel_ like you're going too slowly
 and you'll find excuses not to do it while the product manager is
 badgering your team lead about the roadmap and the scrum master is
 cheerleading everyone in standup to get a few more tickets across the
 line before the sprint ends (yay forcing functions). So, you won't do
 it ("this time"), and that'll reinforce the idea that it's too hard.

The obvious solution here is to practice. Maybe your manager is
 progressive about this sort of thing, and pushes a firm line of "we're
 going to do it right, even if that slows us down initially", but often
 not. Ideally you're in a situation where you can pair with someone who
 already has these practices well in hand, and they can show you how
 they do it and coach you as you do it.

Otherwise, you're stuck in a situation where you have to either force
 the issue at work, which could mean pushback from your colleagues and
 management (and follow-on negative consequences), or practice on your
 own time (which is its own can of worms - tl;dr it's shitty to expect
 people to do job training as unpaid overtime and be happy about their
 "hobby projects").

Another part of the problem is what I'm going to call "not enough
 grounding on OO theory", which doesn't have to be academic and could
 just as easily amount to "you haven't practiced these dozens of
 patterns often enough to make them second nature and be aware of them
 all the time". This is a "forest for the trees" problem - you do a
 bunch of quality-of-life refactorings like Extract Method, and one day
 you realize your class has thirty private methods that're impossible
 to nail down with tests. Clearly you - or someone - missed a chance to
 extract a type from all that, but where was that line? Now you're back
 in "this is going to take ages to fix, maybe I should put a refactoring
 ticket in the backlog and leave it for now" territory.

How do you fix _that?_

I don't know.