It's true that a dirty "fix" is not a fix (a). If a product has a problem, a clean fix is intended to fix this problem to be able to:
- Reuse the concerned part of the product and be sure that there are no known issues with it,
- Don't have to return to modify code again later to solve bugs.
With a dirty fix, the developer:
- Can't reuse the concerned part, because she cannot be sure that it will work as expected,
- Must return later to rewrite the code correctly.
So instead of spending more time fixing something, a dirty fix is used to spend less time immediately, but more time lately by forcing to return and make a clean fix and by forbidding to reuse code meanwhile.
Of course, this may not apply to every dirty fix, and it also depends on what we call a dirty fix or not. Example:
A user submits a report saying that a program gives an incorrect result when the input is equal to 39.5. A stupidly dirty DailyWTF candidate fix would be to do:
if (input == 39.5)
// 14.7 is a correct result, calculated by hand.
output = 14.7;
// Keep the old and broken algorithm.
Chances are that in a few days or weeks, another report from another customer will tell us that the output is also incorrect for some other input value.
A less dirty fix would be to check the algorithm, see where is it broken, and fix it, without fixing the unit tests. The chances to see it break again are smaller, but it can happen, and there is a need to return later to add unit tests, maybe add comments, enforce style guidelines, write documentation, etc.
So yes, some fixes dirtier than others (b, c). If some are more acceptable than others is up to your company guidelines.
Dirty fixes show a pragmatic use of ones time (d, e). At a precise moment. Because by spending a few minutes less, you waste hours of your own time lately (or your colleagues will spend later hours cleaning your fix). That's why dirty fixes should be discouraged especially in a team. If a developer makes lots of dirty fixes, then leaves the company, the other people of the team will have hard time cleaning the fixes.
How do we stop attitudes like "dirty fixes show a pragmatic use of ones time and should not be discouraged" from becoming standard practice?
By enforcing best practices, but also by ensuring that the developers in a team/in a company communicate well about what they're doing. Too much pressure and stress from management can also force the developers to use more dirty fixes just to finish quickly. This is especially true when the team manager is inexperienced enough and/or don't care about code quality.