mjh 45389 (2/11/2016)
Some years ago the company I was working for then brought in a new support manager whose experience was in engineering manufacture but not IT. He devised a new system for categorising faults based on their priority from Critical down to Trivial. These were reviewed every week in a Monday morning meeting where he defined the order faults/bugs were to be tackled. After some months some of us (bug fixing taking around 20% of my time) asked how much time needed to pass before a trivial bug was upgraded. His view was never. After he had been there some more months major clients (major financial institutions and others) started shouting loudly about the trivial bugs and work arounds. It was not long before he joined the job market!Many factors come into deciding timescales!
It sounds like he should have focussed on the "trivial" bugs, while they were still seemingly trivial. A trivial bug allowed to linger long enough will become a critical bug. The same can be said for security vulnerabilities; it starts as something simple, like a single miscoded line of code which should have been caught by a code review or testing. Once in production it results in a buffer overrun. Time passes and no one notices at first, but then eventually someone does, and then the exploit gets advertised across the web. In the interim the issue may have been raised to the attention of the development team, but a malicious hacker beats them to the punch and uses the exploit to break into the system.
"Do not seek to follow in the footsteps of the wise. Instead, seek what they sought." - Matsuo Basho