An SEP is something we can’t see, or don’t see, or our brain doesn’t let us see, because we think that it’s somebody else’s problem… The brain just edits it out, it’s like a blind spot. If you look at it directly you won’t see it unless you know precisely what it is. Your only hope is to catch it by surprise out of the corner of your eye.
Douglas Adams, Life, the Universe and Everything
Good news everyone! The SEP field exists and it’s all over your codebase. Seriously, look carefully through your code and check how many things were supposed to be refactored soon-ish but never did?
During my almost-four years at Disqus I noticed that whenever I wrote something in a hurry, rushing to get a feature (or a fix) out, my creation tended to posses this weird ability to make itself invisible while slowly growing in size and complexity. Then, one day, I would be explaining our codebase to a new engineer and suddenly notice that this code somehow affected the overall architecture and that lots of other stuff now depend on it.
This happens to all of us because Very Important Tasks tend to be followed by more Very Important Tasks. So by the time you need to return and refactor your code you’ve already forgotten all about it. It is now officially Somebody Else’s Problem.
I’d like to note here that I’m talking from my experience of working in a small company. I have absolutely no idea what happens when you have thousands of engineers and can afford concentrating on that one thing. All I know is that in small teams, everyone has tons of responsibility and your task list never gets smaller.
Does this mean that you shouldn’t rush things? In an ideal world—yes. But in the real world, the it’s done when it’s ready policy doesn’t always work. We all have deadlines, competitors, big events, and deploys that break everything. In such rare cases, you just have to suck it up and make things happen. War is war, after all.
But it is extremely important to not to let this war mindset take over you during the peace time. Because otherwise all you’ll end up with is shitty code and we all know that shitty code is bad, mmmkay?
So next time you’re rushing to push your patch upstream, think about this: what are the chances that your company will go out of business if you take an extra few hours (or days) and make your patch better? And what are the chances that a week from now you will have another Very Important Task and won’t be able to get back and refactor the code you barfed out today?
The answer is that in the majority of cases you can afford to take the extra time to improve your patch.