Hacks cannot be Good Code Too

Hacks, by definition, they are not optimal solutions to problems and thus cannot be considered good code. Recently read this article: Hacks can be Good Code too. It tackles the big question of how to decide to do it the “Right way” or too just to ‘hack something together’ quick and dirty. The author of the article uses a framework of questions you should ask yourself when having to decide what you are going to do.

It got me thinking, can hacks really be good code at the same time? The article suggests using a couple of interesting questions, I will go through them one by one.

Note: The first time I read the article, I did not notice that there is another paragraph after the table at the end of the article. In the last paragraph, the author writes: “Would I have done this on a team project or a commercial product? Absolutely not.” - However, I already wrote down my thoughts, so here they are.

The Questions

Do other systems touch this code?

If nothing depends on it right now - it would seem ok to add a hack, however you also have to consider the future. How will this effect the Extensibility of your code?

How many developers will need to interact with it over time?

It’s always difficult to predict the future. As long as it is your own personal project - then go ahead and use a hack. In any project larger than a personal project, you should show some empathy to the next developer and do it the right way.

How much work would be involved in building out the correct approach?

If the new function you are adding to the existing system is overly complicated and has to touch a significant larger portion of the code. You may have just detected an architectural flaw in the code.

You have to then actually split the task into two parts: Refactoring/Restructuring the existing code and then implementing the actual requested feature. Is after the refactor, the part of implementing the new feature really more expensive than using a bad approach?

How much work would be involved in building out the bad approach?

This is hopefully just a silly question, the assumption would always be that the ‘quick’ hack is not going to take less time than the ‘right way’.

In reality, it is often the case that the customer really likes the new feature, and then you will have to extend it with more additional features. The hack can become very costly for you in the future.

How valuable is the intended feature?

I would skip this question. It is unclear what ‘value’ even means. The value of the feature is totally different from the perspective of the developer, the client and the user of the software.

Let’s take a simple example: Add logging to the code. For the developer valuing time, future debugging time will be drastically reduced, from the clients’ perspective this is great as he values money, and he has to spend less on debugging and the user has no direct value from this.

However, in reality it comes down to external factors. Like, the customer needs to show a new feature to his stakeholders. So there is a high value / reward for completing this feature as fast as possible.

How much additional maintenance does the bad solution require?

You really cannot predict that, it is totally dependent on how long the code is going to be used.

I would be very concerned about unintended side effects. Other developers would see that using ‘hacks’ is ok and when creating new features in the future they will also take the quick and dirty solution. Which then in the long term will degrade the software quality and drastically increase the maintenance cost.

When would I allow using ‘hacks’?

Before I consider using hacks, I would first look at the lifecycle of the project. In which phase is the project?

Phase	Description
Initialization / MVP Phase	Use as few hacks as possible, be aware that you are going to have to clean them up in the ‘Stabilization Phase’ - be aware that the ‘stabilization phase’ may never come, and you jump directly into production.
Stabilization Phase	No hacks allowed, literally the phase to clean up ‘hacks’
Production Phase	Hacks to be avoided if possible. If it cannot be avoided, add a comment in the code why the hack was used, and notes on a possible clean solution.
Legacy / End Of Life Phase	Use as many hacks as you want, the code is not going to be used anymore.

Conclusion

Hacks, by definition they are inelegant solutions to problems and thus cannot be good code. They can however be an appropriate solution to a problem when you are in the correct project phase.

The article continues that he used this hack only because his blog engine is very old and is “It’s well beyond needing a massive rewrite”. I would agree with the author, he made the right call to use a hack in this situation. The project is in the ‘end of life’-Phase.

It is ‘good code’ because it added the new desired feature without an excess of effort. But as the author also agrees. Never do this in a commercial production.