If you’ve worked at, or talked to, some developers at various software companies, there is one theme that often returns: developers blush when thinking about the central part of their app code, and would like nothing more than to finally clean up that mess, once and for all.
And it’s not something ‘non-core’ they wish they could refactor. No, it’s the central part of the codebase. The checkout code in an e-commerce platform. The friend invite mechanism for a social network. The formula engine in a commercial Excel plug-in (to name just three I’ve seen up close). When asked to make a change in that code, chances are the reaction looks something like this:
Why is this such a common theme?
The reason is, I think, threefold.
1.The most important code is for the oldest functionality
Actually, I’d say even more: it’s the code of your minimal viable product. The code you wrote as a proof-of-content to see all excitedly how it works! The code that you deem worthy of building nothing less than a business around.
The code that you built after-hours during your day job, while also learning the framework you use for turning it into a web site.
You can see where I’m going. It’s the code you wrote before you learned many lessons about you specific project, and sometimes even about the framework and/or technology it is written in.
2. The most important code is the most affected by customer feedback and product improvements
Sure, you should be tweaking your signup flow. But usually, that one is just a series of steps and forms, and you’ve done it a thousand times. Customers, whose feedback you care deeply about, don’t care about your signup flow, because they already took it and forgot about it.
The code that is central to your app? That’s the one they have a thing or two to say about. So you add a small exception to please that one early ‘poster customer’. And another exception because you didn’t need team collaboration and e-mail notifications in V1, but realised the added value of those in V2. And another exception that makes it work in French.
And you’re a lean startup, so you iterate fast. And break things. But then you fix it again. But refactor that code that so many of your current clients rely on, rather than just adding functionality to it? That’s not business-critical, so you just vent and sigh, and postpone it.
3. The most important code is the hardest to fully grok for new developers on your team
If it were easy, you wouldn’t have built a business around it. So it’s the code that you poured all your vision and oversight as a founder in. The class structure is elegant, the performance well-tweaked. You know exactly where any improvement to the code fits best because you have the whole picture in your mind.
But then you hire John The Junior Developer. And after a ramp-up period and some small bugfixes and fringe features, you deem him ready to Touch The Core Code.
But John doesn’t know your vision. John just wants to fix a problem or implement an enhancement. And that’s why John reads through the relevant part of your core code.
And so he uses an IF statement rather than a subclass, because god knows what all that scary stuff in the base class is about, and it doesn’t seem to have much to do with team collaboration or e-mail notifications anyway.
The most important part of your code is also the messiest. It’s also the most valuable.
The core code of your app is like a veteran battle-hardened warrior, scars included.
So, when for the umpteenth time a new developer joins your team, and when you walk him through your code, he backs away in disgust, or burst out in hysteric laughing, loudly wondering how you ever made it to a point where you have a hiring budget using that shitfest of a code base, don’t despair. Keep your head held high and point them to this article.
Also, the good news is, as I’ve said at the start: while this phenomenon is quite common, and I’ve certainly been guilty of it for personal projects, it doesn’t always have to be like this. The smarter tech companies I’ve seen schedule precious senior developer time regularly to dive in the core code, and make sure it stays performant and in pristine condition. Consider adding this one to your ‘things to ask during the job interview’ list.
Last but not least, I’d like to point you to Joel Spolsky’s ancient but still valuable (hah, how appropriate!) article of the strategic danger of a full app rewrite. Don’t go that far.
This blog is still quite new, so if you liked this post, I would love for you to Tweet it and help spread the word!