Edit: Obviously, I'm not GP, but here's my take on this. > doesn't clean code always deliver a higher value as opposed to, say, messy code? I'll agree with yo

Edit: Obviously, I'm not GP, but here's my take on this. > doesn't clean code always deliver a higher value as opposed to, say, messy code? I'll agree with you there, but I'm under the impression that the phrase "clean code" is somewhat too ambiguous. Coding style per se is very subjective anyway, so obsessing over it propably is not a good thing in most cases, yes. But if the "quick and dirty" approach also influences the architecture of what you're developing (i.e. it also affects other code) I'd very well argue that taking a stand against it is a good thing to do. On a similar note: I find the notion of "technical debt" to be quite useful in a lot of ways: By taking the short path, you'll be forced to make up for it at a later date, be it through slower development, a lack of reliability or the necessity to clean up the "hacks". Where the metaphor breaks down (and seems to be contraproductive) is that it leads many business people to assume the debt (i.e. the negative impact) will be easy to quantify and can be treated like some other expense (and thus it often is ignored for far too long). So, the first thing I ask whenever the "business side" asks for a quick and dirty fix for something (often mainly because of some production issue) is "When and how are we going to fix this properly? How will we deal with the downsides in the mean time?". This usually achieves my goal of making them think about the implications more -- I don't believe that's a very viable strategy in bigger companies, though.