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.
- 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.
- 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.
Top comments (4)
One of the biggest problems I've seen with having to do hacks is management insistence that they be done regardless of the long term technical debt. This is especially true if the management involved are not software people (marketing/sales, mechanical engineers, accountants, etc...). They just want it done, NOW, and don't care what the long term consequences are. If you are foolish enough to try to convince them that not hacking something on the fly is the best solution, expect to be told you "aren't a team player" and, perhaps, getting put on a "performance improvement plan" to improve your attitude (ie so they can build an excuse with a paper trail to fire you for cause).
On some companies that is true. The company culture, when it comes to situations like this, is very important. Hacking away at a code base is a short term job.
"Yes, I'm sure that tool you're now creating will be used only once to import data!" So it was hacked together with lots of assumptions.
So, it got used once.
And again. So it failed or introduced duplicates.
So it got 'fixed', and used for years.
I've see that happen. It was being "fixed" on a weekly basis.