I tend to find that as soon as you mention population management people start leaping around and accusing you of talking about genocide. Actually my plan is always to advocate equal (or superior) education of women and equal rights. Wherever that happens the birth rate drops below death rate and you have a suitable planet saving decline in humans.

The genocide fear just shows the small minds of those who squeal about it.

Your best bet is to simply add tests for each thing you fix. Don't bother with wider testing. But do add a new test every time you break something (for the thing you broke) when fixing another bug.

And if you are adding tests make sure they are for run automatically after changes to the code base so that they are always run shortly after changes are submitted (I'm assuming it's under source control, if not get that sorted first).

Such metrics exist. I've seen the evidence in the past with regards to software for automotive control (running the engine). Basically if you have to recall 300000 cars to be fixed at your cost (even just an ECU software upgrade) you have at the very least say 300000 hours of technician time and all the rest. Plus possibly if it was bad a few lawsuits to burn cash defending or paying out on.

I think full life cycle metrics in automotive put bug fixing once a vehicle was out the door at something like 50 - 200 times the cost of finding it early on during design reviews, code reviews and ultimately testing of unit, module and system as different stages.

But in that instance you are talking scale of units in the millions ultimately with many years of life so many millions of operational years in which bugs can bite! Plus the goods are high value. If you are talking low value goods and a few thousand copies well loose it under GPL with suitable disclaimers of suitability of anything is denied:-)

You get the picture, you might not be able to prove what you want because it is a time money equation with varied parameters.

In short you need the metrics for what you are focussed on and gathering those metrics may cost more than it's worth. The collection cost itself is a similar time money equation to consider in advance. Reality for contractor style companies is they don't want to bother testing because they get to fix the things they break in adding features for you or fixing other bugs. Testing is a path to being redundant.

Surely this is just proof of gravity and relativity. The more persons in a queue with full trolleys the slower time moves for them due to the gravitational distortion of the trolleys and shopping mass?

"see the light" - you are making the assumption of it being something that casts light; I suspect Linus Torvalds judges on presented evidence and so far apparently judges the argument hasn't been carried.

Surely he sues them for breach of copyright as they clearly had no right to distribute his copyright work. He can after all show loss directly consequent of the copyright material being distributed.

But both should exist if the lines that mark interfaces are drawn in the right place.

Faster hardware tends to be the source of the problem. It makes people lazy because they don't have to attend to the details.

So it's about the worst cure that could be taken.

You presume that a month or twenty down the line the original author can still maintain it. Most crappy code that doesn't holds as true.

I agree from a different view that goes like this. Good programmers/software engineers are expensive so companies like to pay cheaper people. To enable use of cheaper people tools and processes are introduced.

One such tool is languages that have buckets of libraries or core tools that the new people merely have to extend or tweak.

Knuth is lucky that most things he needed didn't exist then so using libraries wasn't an option. If everything he needed already existed he'd have picked a different area to work in.

The code base I work on would be improved by a rewrite. But in doing so it would actually be a matter of putting more effort into using the libraries (they do too much manual string manipulation for example that could be done using existing library calls; it's Qt based stuff).

At the same time it would cut lines of application code and make seeing the algorithm easier. I've just swapped 2500 lines for 850 lines whilst increasing functionality.

Cost benefit wise it's impossible to say in advance was it worth it.

The real irritation in Britain with similar convictions (speed wise not video evidence wise) is bikers go to prison for sometimes a year to 18 months. But company directors who are responsible for those people who work for the company often get caught doing similar speeds in big cars but just get a fine and short ban.

Despite the simple math showing that the killing force and actual likelihood of incident in the first place (due to cross section and time in that zone) being way lower for the bike than car.

I'm not grumbling about the convictions (caught breaking the law and proven so equals conviction) merely the imbalance in consequence. I often think shouldn't the director go to prison longer as he wasn't only risking the physical result of his action but the livelihoods of all his employees (subverting their own defence lawyers arguments.)

The Bluetooth members meet 4 times (I think) per year at week long unplug fests where they all try their current and coming components against all other attendees to make sure they work together. They rotate through short time slots (almost like bluetooth channel hopping:-) to try and make sure every device meets every other.

They spend a lot of time often sending 5 or 6 teams with different items each to test. So if a claimed bluetooth device has problems the maker probably bought the cheap poor chip rather than marginally better component.

Price I think you'll find. It is only the last two years that the price on the bluetooth chip has been low enough for it to begin proliferation into low end (price wise) consumables.

Unless the mechanical flaw has it wedge open like the terrified owner of motorbike I once encountered who had survived the down hill of a Welsh mountain road with the throttle locked partially open.

Where as the multiple sensors for throttle position make it more reliable as two of the typically three can fail and it still operate correctly.

The cleanliness of electronic control can actually help and reduce risks in these kinds of places because the results of time and poor maintenance are more predictable.