Thread by @RonJeffries

It's amazing to me how many people seem to want to support [sometimes] not writing clean code.

The argument most often made seems to be "Sometimes it's more effective to leave the code crufty and get it out there."

I suspect that's not always the real concern.

1/13

If someone were not as adept at refactoring and design as they might be -- and that's all of us -- then they might be right that moving toward a good design slows them down.

Certainly if one were totally inept at design, refactoring would be pointless.

2/13

So, somewhere between absolutely horrid and refactoring goddess, there is a point where refactoring pays off, and before that point, it doesn't.

But this is not a good argument against refactoring.

3/13

"I'm not very good" is never a good argument for doing the wrong thing. If anything, the not-very-good person ought to do more refactoring, learn more design, so as to have a chance of surviving in this dog-eat-dog world of miners at the code face in the code mines of ohio.

4/13

(Sorry, I was having too much fun there.)

Anyway, refactoring all the time toward good design has been found to be a good thing by the folks who get "good enough" at it, and I suspect that if it's not a good thing for someone, then that someone has some learning to do.

5/13

I don't mean that to sound arrogant. I do mean it to sound firm, however. When someone who's expert at something tells me, who isn't, that some practice is a good one, it behooves me to listen. Most of what little I've learned has come from following that practice.

6/13

Another possibility is that when we leave our code less than perfect, we don't want to be made to feel guilty. So we push back against the "always keep the code clean" idea, lest we have to feel guilty because we don't always keep ours clean.

7/13

Well, here's a news flash. I don't always keep my code clean. If you've read my programming in public articles, you know that. I get in trouble with bad code Every Damn Time. I'm not faking that. I try to keep the code clean, and EDT, it's still not clean enough.

8/13

And Every Damn Time, it slows me down. And since I refactor a lot, I have a good sense of how long it would have taken to clean up and avoid the problem, and (it seems) invariably that cleaning sooner would let me go faster.

9/13

But I don't feel guilty about that. I feel a bit stupid, but if you can program at all without feeling stupid, I'd like to know how. I think you just have to get used to it.

So I'm used to it and I try a little harder next time. No guilt, just stupid.

10/13

And, next time, I'll hit a green bar, maybe clean a little, and I'll be quite aware of something that's not quite right, and I'll ask myself if it's worth going after, and I'll decide that it isn't.

Some day, maybe I'll get away with that. Maybe sometimes I already have.

11/13

We always decide to stop before perfect. The trick is getting close enough. My experience is that I almost always fall short, rarely if ever go too far toward perfect.

So my advice is, push a bit further for cleaner code: you'll go faster.

12/13

Of course, in the end, you should do as you wish. But I wish, and hope, and condemn you to a growing awareness of the consequences of your decisions, not so that you'll suffer (we all do) but so that you'll suffer less.

13/13