No commercial system is perfect – I added “commercial” because you could technically create a one-liner program that prints text to the screen. It matches your specifications exactly to print a line of text, thus perfect code.
Commercial systems, one that you can really sell and earn bucks, are far less than perfect. Bugs occur due to individuals – pure carelessness, lack of skill, too much code to handle for a single programmer; due to team – poor design, poor management, poor leadership, wrong use of tools, technology, architecture, design; due to customers – poor requirements, miscommunication, scope creep; plus so many other reasons for any bug.
Level 1 people still expect bugless code: clients who do not accept products with known bugs, or developers who try to fix every known bug to try achieve the bugless state. Level 2 developers understand this imperfection, but anyhow choose bugs to fix: the most common mistake is fixing bugs that are “easy to fix”. However, that bug may not have a big impact or severity, instead increases chances of introducing new bugs (as described below). High-level people like Eric uses a process to determine which bugs are worth fixing.
Eric approaches bugs in a well-defined process: After a bug is reported and confirmed, a decision must be made to FIX or NOT FIX the bug. This is because:
- There is a time constraint to fix all bugs
- Fixing a bug may introduce more bugs
The bug is analysed in terms of Severity, Frequency, Cost, Risk. The first 2 relate to the client: what the impact is and how often is occurs. The last 2 relates to the developers: how difficult / how long to fix it and the probability of introducing more bugs.
The recommendation is to plot the first 2 factors on a graph. Always fix stuff in the top right corner and never fix stuff in the bottom left. The factor ratings might change over time, such as a miscalculated risk. Re-visiting these factors when they change can allow us to make better decisions (including rollback bugfixes).
[1] is a condensed version of what Eric wrote in [2] originally.
[1] http://technology.guardian.co.uk/weekly … 95,00.html
[2] http://software.ericsink.com/articles/F … tions.html