This Is How Your Code Gets Nasty

I think it already happened to you that you had to work with legacy code that was pretty nasty. And you blamed the developers who formerly had written the code. Right? I think it is not the developers who have to be blamed. I would even question if there is anybody who can be blamed.

The code is born

When you start a project from the scratch first you design the architecture of the application. During the architecture design process you consider not just the features in the specification but also try to get the architecture ready for some possible future features. It’s not easy to predict what feature requests may come up in the future, but if you can consider at least some of the possible features then you can make your code stay clean longer.

The problem that you will face

Sooner or later the time will come when the implementation of a new feature will be in conflict with the architecture or the code of the application. The reason of it is very simple: you are not able to prepare for all the possible future features when you design the initial architecture or when you write the code of the current features. In a situation like this you have 4 options:

1. Code Refactoring: You change the way the existing code is written. If you are lucky you need to refactor only some part of the code to make it “compatible” with the new code that you will write to implement the new feature.
2. Architecture Refactoring (rearchitecting): you change the way the existing code is organized in logical layers and components. This requires a huge effort and may take a lot of time.
3. Rewrite: you redesign and rewrite everything from the scratch considering the new feature. Either only some part of the application or the entire application is rewritten. It hurts when you even think of it.
4. Fix with a dirty hack: Somehow this is the most common solution – a dirty hack, because usually this requires the least time and effort. But this will make the code nasty. The more hack you do the more nasty the code will be.

In an ideal world every software engineer, developer would choose option #1, #2 or #3 and would never choose #4. But we don’t live in an ideal world. Business owners, investors push managers, managers push engineers to deliver as early as possible. The business short term goals usually override the engineering long term goals. This is the reason why option #4 is chosen over the other 3 options many times. Ok, then let’s blame the managers! No, still let’s not blame anybody.

I’m a one-person entrepreneur. I’m the business owner and the software developer of Bookmark Ninja at the same time. How will I decide, what will I do if I have to face a situation described above? It’s a kind of a schizophrenic situation. As a developer I definitely want to avoid choosing option #4, I always want to maintain a clean code. But as a business owner I have to consider other points of view, too. There are competitors out there. Time is a key factor, if I don’t react fast enough I may lose customers. If I lose customers I lose money. It’s not just about enjoying the coding and programming. It’s about the business, too. A real life business.

Balancing

We always have to examine the business impact of the different “code friendly” options (#1, #2, #3) and also have to think about how nasty the quick hacks (#4) will make our code. Then we have to decide. It’s a kind of a balancing. But the bottom line is that we have to accept that there can be situations when a dirty hack is the right decision. This is the big difference between programming in school and programming in real life.