I’m a zero-tolerance person when it comes to defects. I like all my tests green. If anything comes up red (either in a test or a as compile error) then it is my No.1 priority to fix the defect.
This isn’t a dogma – it’s a purely rational approach for various reasons:
- Efficiency: defects are most likely to result from changes / additions you have just made. Better to fix them now while you have the context in your head. Coming back to old bugs is always painful, and will take you much more time than if you fixed them in the first instance.
- Redesign hints: a defect is often a sign of a design error. Did you make code too complex? Are you repeating yourself? Are you playing fast and loose with concurrency? Fixing the error is often a good opportunity to revisit design decisions and refactor – in the long term this will pay off better than just patching the code to fix the immediate error
- Unblocking progress: an error is likely to be a roadblock – sometimes this is enforced (e.g. a compliler error) but at other times because it stops you from otherwise proceeding on a priority task (e.g. testing some key subsystem)
Anyway, I don’t think fixing defects immediately and properly is a particularly controversial viewpoint.
Which brings me to warnings – I view warnings as exactly the same as errors but with precisely one key difference – you are allowed to defer fixing them. I’ll give a few examples:
- My Maven build is currently spitting out a warning “Using platform encoding (Cp1252 actually) to copy filtered resources, i.e. build is platform dependent!” – yep, clearly something I should fix, but as I’m only building on a Windows box right now it’s OK to defer this one.
- Refection warnings in Clojure code – these cause a lot of unnecessary performance overhead and can be fixed quite easily with a couple of type hints. Nevertheless, it’s only an optimisation and can be deferred until the point you need to productionise / optimise your code.
- Code style warnings for “unreachable code” – this often isn’t causing any immediate harm but it makes future maintenance harder if you need to review / understand what is going on with redundant code. Better to cut this out and reduce your technical debt. But again it’s not top priority to fix immediately – it sometimes makes sense to fix these kind of things en masse as part of a wider code cleanup task done once a month or so.
Interestingly, this line of thought leads you to regard warnings as a measure of technical debt. Here’s a thought experiment – if your IDE was a sufficiently advanced AI that could identify *all* issues in your project (design, architecure, variable naming, insufficient documentation) and provide warnings on these, then what you would have is a work list for eliminating all technical debt.
Furthermore, if you could also estimate the time required to fix each item, then you would actually be able to put a time / money cost on technical debt. All the software-metrics guys and IT management types will no doubt be salivating at that prospect…. since they will finally be able to put a quantitative measure on the trade-off between “doing things right” and “quick and dirty”.
Anyway, I see a promising business opportunity to sell a warning => cost estimation tool!