Something that has always bothered me, in my programmer career is building code for the short term, or the temporary hack, that will remain forever in the code base. I find it that temporary hacks are nothing more than ignorance on how, and how long, it takes to solve a specific problem.

“There’s nothing more permanent than a temporary hack.” — Kyle Simpson

Does this mean I have never done it? Of course I have, and all programmers have done it at some point in their career and, like me, will probably do it again.

So we do it on purpose, right? Well yes and  no.

Yes because we are pressured by deadlines to deliver a product on time and on budget. A good developer that does this on purpose is aware of its problems, so it takes notes and/or creates an issue on the issue tracker to solve it a later time. The problem here is the “ a later time ”. If your teammates and management in your company don’t understand that it has to be done, this will, almost every time, come bite you in the ass at a later date.

How? The two most common scenarios.

1. Another hack will be made to compensate the shortcomings of the first one. This will pile on and a third, fourth, ad infinitum, hacks will be made to compensate the shortcomings of the previous one.
2. Since your name was on the commit and due to the shortcomings of said hack, you will take the blame for the time it takes to “fix” the hack — see scenario 1.

This eats away at the productivity of your team and causes a sunken cost. The reasons for this cost are not obvious. The only thing that is noticed, by management, is that more money has to be spent on the project.

If someone on your team does not take notes on the hacks, this is a sign of future pain and suffering for the entire team.

Every month or so — your mileage may vary — some time should be set aside to solve these issues or risk getting drowned in them.

No , because the developer is unaware of the problems due to having low experience on how the code affects the code base. This is either inexperience as a programmer or inexperience with the code base itself. These hacks work great in the short term and give the appearance that the programmer can work in any environment, but is only leading to technical debt.

And these debts will be paid with interest.

If you scale of perfection is 1 to 10, with 10 being perfect, then always aim to 10 even though you will never get there. You will reach, hopefully, an 8 or even 9, but if you aim to the 8, you will be content with a 6 — until the day you have to maintain that code.

So my new year’s resolution will be to avoid hacks whenever possible and make sure my teammates understand the consequences of technical debt. Use mentoring, use technical tools — code reviews — or anything that is required to make sure everyone is on board.