Geoff, I'm going to pick at
Geoff, I'm going to pick at your word "trivial". I worked at Microsoft for quite a few years, and while there are many things related to the software development process that company could do a lot better at, one of the parts they do with industry-leading excellence is shut down large projects for shipment.
There is a process where a 'bar' gets slowly raised over time. For a bug to be chosen to be fixed, it must 'meet the bar', i.e. be worse in its impact than the bar. Early on, trivial bugs start getting punted. After a while more serious bugs start to get punted. By the last month there is a 'war room' with a panel of software engineering experts that each and every bug that is going to be fixed must be taken to, where both the problem and the fix are reviewed and a risk assessment (both of the fix and of not fixing the bug) is performed. (Most teams punt nearly all their bugs on their own and only take the most serious to war room).
Its is always the case that rather serious (non trivial) bugs pop up late in the cycle that get punted because the potential impact of the fix is riskier than the problem, even though the problem is significant. It comes down to a 'can we live without the fix' decision.
This is for major software, like windows and other big microsoft products. Part of the calculus is that there will always be another chance to fix bugs later - a service pack, or another release.
Joe's conversion case is somewhat different, the conversion is only going to be done once, and there is no way to improve it later, but Joe has to manage the same 'bar' and at least informally go through the same mental process of risk management for each reported bug.
For each bug, Joe is going to have to evaluate the number of threads affected, the impact to those threads, the difficulty involved in manually fixing the issues later, and the risk of making a change (the risk that making the change will introduce new problems). As a non-software expert, he's going to be making a lot of SWAGs. He can ask the devs the cost of doing a fix and judge a little based on that, but without knowing their personal track records he won't know which ones are more credible (and safe) than others, so it's a crap shoot. And unlike the war room, he doesn't have the luxury of saying 'show me the fix before I decide whether to take it'. War room evaluates the safety of the code change by reviewing line by line the code (even though the experts are not experts on the particular code base). They look for how many different places are being touched, is it a large fix, a section rewrite, or just a one liner. They do have some background on whether the component is a bug farm or very stable code. Code in bug farms is less likely to get fixed late because there's more chance of introducing another bug (or two) because that code is such a mess to start with.
One thing Joe shouldn't do is be swayed by the squeaky wheel syndrome. If a bug affects just one user's threads, and is possible to fix later, it shouldn't be fixed at this point, no matter how vocal that user is and no matter how many times that bug gets re-reported. That's tougher to do in a community like this, but it has to be done.
At this point, Joe should be punting all trivial bugs plus those that are not trivial, as long as they can be lived with or corrected later. He should be punting anything that only affects a few threads, regardless of how badly those few threads are affected. It's really down to show-stoppers only.
The discipline must come from development management, the young programmers can't be relied upon to do proper risk assessment. That's at least as true in this case as it is in any US company.
Well that's my sermon for today, I'll put my shoe back on and stop pounding the table with it.
