Going Backwards To Go Forwards

I’ve been a programmer for a fair amount of time, now, and in that time I have yet to see a large codebase where compromises haven’t been made along the way.

You can start out with the best intentions. You can carefully plan the architecture, draw diagrams, and be generally committed to making extensible, flexible code.

But then, some deadline approaches, some other task takes priority, and you end up making a call to “just get it working”. Maybe not in the most elegant way. But good enough. And, of course, you plan to go back and tidy it up later.

These…let’s call them “fudges” (I wouldn’t even go so far as to call them hacks)….they accumulate. Like entropy building up in your pristine code. Because you almost never have the time to go back and fix them.

And as those fudges accumulate, you start to feel more…friction…when you work in certain areas of your code. The kludges bug you. Every time you encounter them, every time you have to work around a work-around, you remember that you intended to fix this part of the code, give it some time and love, make it beautiful and pristine again.

It’s a desire every programmer feels growing over time, working in larger, older code bases – the desire to refactor.

But, if you’re running a commercial enterprise, the time pressure never goes away. Time is money. You’re always faced with the decision – leave it as is, accept the small cost of working around the fudges, or make the more significant investment of time refactoring your code, in the hope of future gains.

Do you trudge on grudgingly, or do you take one step back to make two forward?

But there’s another risk that dogs programmers. The risk of over-engineering and the perfectionism. Good programmers love beautiful, elegant code. But it’s a love that can lead programmers to futz around for ages pursuing “elegant designs” where “good enough” does just fine.

The trick is in knowing when it’s genuinely worth refactoring, and when that’s just your perfectionist side calling you, siren-like, to smash yourself against the rocks of your deadline.

I’d love to drop some pearl of wisdom here, some clear trick to knowing when the time is right to refactor. But I can’t say it’s anything other than experience. With experience, your instincts will develop, you’ll get a feeling for when working around messy code is taking more time than just sitting and fixing it.

And then, once you develop that experience, you have to try to make your case to your project manager, because they’re always under pressure to get the project complete. You have to convince them that it’s worth it to give you a buffer of time to get the code…basically back to the point it is now, with no visible new features added.

If you have a good PM, they’ll understand the necessity. But even if they’re on board, it can be hard to find that extra time.

Luckily, I am my own Project Manager. Which means I can do what I want hahahahaha…

…no, not really. It just means I have all the stress of trying to make the right choices for time and task allocation on top of my other responsibilities, and it’s all on me if I fuck up.

No pressure.

Anyway, the point of this post is to update you, dear reader, on what I’m currently working on. As you might have guessed, I’m refactoring the System Crash codebase. There’s a new Cults feature that I was in the process of implementing (which I will talk about when I can show it to you), but halfway through that I decided that fitting the new code in around some of my previous code fudges was too painful, and that the time had finally come to do a bit of refactoring.

Let me end this post with a screenshot. Because a picture says a thousand words. Behold, what my workday looks like.

-Gareth out.