I agree that there needs to be a balance. I disagree that hackathons are the solution. Hackathons are usually what management comes up with when they think ab

I agree that there needs to be a balance. I disagree that hackathons are the solution. Hackathons are usually what management comes up with when they think about this problem. However, I guarantee you that this conversation regularly happens among your developers at Friday happy hours: - So how's that project Z going? - You know, same old. Looks easy in theory, and every little task is a slog. I spent this whole week fighting the Blorgifier again. - Wait, that abomination is still in our codebase? That was a hack we came up with at 3am during one of those death marches last year when we needed to ship something for the Initech demo. - Yeah, you know what they say. Nothing more permanent than a temporary bandaid. I wish I could have a week of my time back. - Yeah... cheers! There will always be very important seeming bugs that have a great definition and visible customer impact. Unfortunately, obscure poorly-defined tasks like "rewrite the Blorgifier" immediately trigger a response of "that's just developers wanting to have fun" in managers. And they end up adding a tax on every single one of those important fixes until eventually the whole thing collapses under its own weight. How to solve this? Ask the developers what's important to fix? Nah, they don't know how to plan a project and don't understand the customer. Does this mean that developer pet projects need to get 100% time allocation? No. But in most companies their time is undersized by a factor of 1000 or more.