As a disclaimer, I'm hoping most of you find this to be insulting to your intelligence. I assume this stuff is common sense.

There's a pattern I'm sure we've all observed wherein fixing the real issues falls to the wayside in favor of band-aid solutions in the name of "business decisions" and deadlines. The well-justified band-aid now and then is an annoyance but continuous implementations of band-aids while the real problem persists leads to something I half-jokingly am calling The Cycle of Despair. It looks something like this.

cycle-of-despair-phase1

The decision to skip the real fix is usually made when the real fix would take longer than just hacking around the problem. Other times, the reasoning is that we don't "own" the underlying problem and we can't wait for another team to fix it. The motivating factor here is time, of course, or at least the perception that it will "cost" more time to implement the real fix. Usually, someone will say something about how "this is a business decision," or some other hand-wavy phrase in a weak attempt to justify the decision. The irritating part about "this is a business decision" is the implication that the engineers are not considering the company's operations as a whole and solely focusing on the problem at hand.

So here's the rub: every feature you implement represents an ongoing cost to the company in terms of time and manpower. This cost needs to be weighed against the benefit the business believes that feature will bring. I've often heard that engineers don't understand business, and, while this is true to some extent (I couldn't tell you the inner workings of accounting tricks or marketing), I can tell you that the concept of time is universally understood regardless of your role in the company. Put simply, the more things I have to maintain now, the less time I will have to work on new things.

Implementing a hack instead of taking the extra time to fix the underlying problem means the underlying problem is still there and there's the hack to maintain in addition to the feature we've implemented. This often makes the loop look like this.

cycle-of-despair-phase2

Congratulations, your "business decision" was to prioritize a short-term win at the cost of additional future maintenance costs. What's personally irritating about this is that person making "the business decision" only feels the additional costs by proxy; it's the engineers who actually have to do the work to maintain the thing. There is a special kind of despair knowing that the thing you're implementing now will result in more (avoidable) work later. Work you have to do. This is sort of like when I was a kid and would just "clean" my room by shoving things under the bed; the mess was still there and it was going to take longer to actually clean. Except in this case, I'm someone's housekeeper being asked to move the stuff under the bed because my employer's friends are coming over and properly cleaning it would take too long, but once the friends are gone I still need to clean the place.

I'd like to believe that the people making the business decisions realize this, but if that's true then it just means they don't respect your time and don't want to acknowledge it.