Buggy code to the left of me, perfect source to the right, here I am, stuck in the middle with EU

One way to improve software is to create re-usable blocks that get as close to a 100% quality as possible. Too some extent this is already done witth softare librarries, but the reduction of code through higher level platforms, rather than workstation based libraries and hoping for th enest when implemeenting will improve matters.

Basically: write less lines of code and build on a major cloud infrastructures. Let millions of other users establish and promote the quality of components.

Gotta lurve the EU.

Once upon a time we went to see a startup in Brussels. LOvely offices. Charming CEO. Talked about EU funding and the importance of marketing to get it. Half a dozen employees, mostly in PR.

Finally I aksed, 'But what does your company actually do?'

'Oh we are funded to investigate and develop a common system of postal standards across the EU for when all the national postal systems deregulate'.

'And who is actually doing that?'

'Oh, we have a mad Russian in the basement with a minicomputer. Lord knows what he is doing.'

Telemetry makes software better?

Wrong answer. And nothing new - Microsoft and others already implemented it - and of course any telemetry have nasty sides, when used in production systems. Feedback is important, but just a big bunch of data without knowing much of the user experience, aims, etc. is utterly useless. It's just another "big data" approach doomed to fail.

You see it in many commercial products - trying to shift testing to end-user without a proper selection and supervision of the tests (to save money) is decreasing the product usability greatly.

Especially since in any large bunch of data you can find a subset that will support any preconceived idea of yours...

"Based on some 108 million lines of code, CAST estimated which problems would need to be fixed and concluded that it would cost about $2.82 per line of code to make those repairs."

What are the chances that these "repairs" will require repairing in their turn? Accept the fact that software is inherently buggy (a bit like the real world).

Love the reference

Gotta love Gerry Rafferty. Keep up the fine work!

€3.25m?

Maybe they could use it better by taking device and software suppliers to court for not fixing the faults that were there from purchase for the full and legally defined "lifetime" of the product, which in the EU is a minimum of 2 years for the warrenty period and usually a few years afterwards for "design faults/failures".

Specifically smart phone security issues but pretty much anything that contains software/firmware is guilty of being abandoned well before it's expected end-of-life.

How many people??

For €3.25m I estimate that you might get around 20 people for a year (I'm assuming "good" people, not those who are barely able to breathe).

This assumes that your overhead is around 100% of salary (if it isn't that could be a problem). Even then for a two year project you get 10 people that will work it out. I just don't see much happening for that little money. Of course, there will be those who say, there is the problem, we need more €€€'s and some nice government agency (I assume there are several in Brussels) will pony up the cash. After all we can't waste this precious research after we have done so much.....

Substantially reducing the bug count is technically quite easy

It's all about incentives. Put the right ones in place, and people will write good code because it is personally beneficial for them to do so.

Put the right incentives in for the PMs, and the testing gets done properly - again, because it is personally beneficial for them to do so.

Put the wrong incentives in place, and you get chaos.

Put no incentives in place and you get the current situation - "ship and be damned". While there is a penalty for late shipment, but no penalty for shipping crap, guess what goes out the door?

Vic.