Something like that is going to vary from company to company. In many larger companies you’re going to have a tech lead/manager, and it should be there responsibility to address the issue and push for getting things done right.

I was working on a bug here and found a work around to get it fixed. I couldn’t find out why it was happening, but I figured out how to fix it. When I did the code review, the tech lead asked me why the problem was occurring, I couldn’t answer him. He then used a good analogy: Debugging software is like being a doctor. If a patient says they have a problem you can treat the symptoms or you can find the problem and eliminate it. It’s obvious to see how treating the symptom is going to continue to create and leave more problems around. Much like your last paragraph explained.

Documenting the extra cost that a hack produces down the road can give you some ammo when those kinds of discussions come up.

Having to hack something usually means something slipped through the requirements and design stages. The real solution to that is to fix the gaps in your process that allowed that to happen.

Of course, if you’re dealing with legacy code, you have to dig yourself out first.

hacks=cheap
managements likes cheap

At my job at least, my Boss knows programming, so the project I’m working on isn’t full of hacks. As he understands that value in doing a more robust solution rather then just a quick and cheap one.

@Jeremy: Unfortunately it’s no more the tech lead’s job to get it done right than it is yours. It’s their job and yours to get the feature implemented as fast as possible, while making sure regressions don’t occur in the code.

@Noah: Unfortunately documenting side-effects is shooting in the dark, unless you can definitively say that the coffee maker will shut down if this code goes in. Most “hacks” don’t produce such clear consequences. If someone were to sit down and say “this code will break feature x”, 99% of the time the person will — in the process of assessing side-effects — come up with workarounds. For the other 1% the person will actually come up with a version of the hack that will not result in the negative consequences.

There’s a reality that new software developers need to understand: 99% of the applications out there have hacks, workarounds, and piles of WTF-quality code. Like Toast says, hacks are cheap and management likes cheap. But on top of that, rewriting code can introduce subtle bugs that break old behavior, and that can often be worse than the pile o’ hacks.

That’s not at all speaking for my employer, I base that largely on experience in smaller shops.

I think I reverted back to my traditional old-man-who-forgot-to-put-in-his-dentures-this-morning routine. As Ryan likes to point out, I tend to sit on my rocking chair and shake my fist at “those yungins”. Sorry guys :)

I forgive you. You ARE far older than us, after all.

@Merovingian: I agree on the level of writing code. My comments were more on the level of coding practices and standards within your company and when they are ignored for hacks. At least where I work, I can put my say in, but the managers have the final say and managers give more credit to what the tech leads say than others.