How bugs per line of code is similar to traffic deaths per car | Hacker News Reader

How bugs per line of code is similar to traffic deaths per car

blog.vivekhaldar.com

44 pointsemuegg29 comments

As people are so fond of reminding here, "correlation is not causation". These data do not imply that:

"some of the things that one might think have an impact on traffic fatalities that according to Smeed’s law do not: better traffic signage, traffic rules, more stringent enforcement of such rules, mass adoption of safety equipment etc."

You can NOT draw that conclusion from these data alone. For this, you need a sample that has the same N/P but differ among the factors above. It is entirely plausible that this graph comes about from the adoptation of such measures, which are only done by societies as the number of vehicles increases.

If you want these data to be explained by homeostasis, you need to show that the risk of dying is the same in all these countries. When judged by D/N, it sure looks like the acceptable risk is not the same, but it's probably not a good measure. Is "fraction of the population dying in vehicle accidents" really constant among these countries? In that case, I'd agree that it looks like homeostasis.

Yeah, it is pretty plausible that the more cars in a country, there more investments will be done in traffic safety. Also because more cars typically mean richer country, which means more developed infrastructure and perhaps better education.

I have a hunch that the number of iPads per citizen also correlates with fewer traffic deaths per car.

You can NOT draw that conclusion from these data alone.

You're right, but there is a lot of other data, and a whole new design philosophy that follows from it (http://www.wired.com/wired/archive/12.12/traffic.html), which I suspect the blogger is aware of but which he has chosen not to introduce here.

His subject isn't actually traffic, after all, but his conjecture about computer code.

I'm aware of the different strategies of roadway safety. However, if the conclusion from the article is true, then there shouldn't be any design philosophy that works, though...

1. Read a chapter from The Mythical Man-month each day before going to bed. ^_^

2. Assumption that when a large project with lots of coders involved grows (and matures) the number of bugs (per line of code) decreases, is very naive one. (see pp 1)

3. Of course, all those useless layers and piles of poorly-designed abstractions we used to see in a typical Java projects are the results of automated memory management and Moore's law. ^_^

If one neglects what is under the hood one will eventually run into a trouble. Memory and its management are still here, like another processes, flows of data and other dynamics. Not thinking about them does not eliminate them from existence. JVM is a user-level process, one of many.

So, it is not a risk homeostasis it is a mere ignorance. ^_^

This is pure speculation, based on an analogy that makes little sense, and, AFAIK, it is factually wrong.

Studies have shown that, all else being equal, there's a linear relation between code size and bug count. I can't find the source right now, though.

There is this study http://www.neverworkintheory.org/?p=58 which basically says after you control for LOC most of the other complexity metrics become noise.

That's the one I was looking for, thanks.

One interesting thing that the theory does is it reminds us that behavior and risk is a two pronged game - we accept the level of risk we are comfortable with, and we indicate our acceptable level of risk by our behavior.

I think it has more to do with culture than number of vehicles, the countries with high deaths are all in West-Europe. I would be able to predict that without even looking at the graphs, in Italy, Spain,.. they drive like a madman in big cities. For most of the other countries, the differences are really minor which imo are random or can be explained by traffic regulations or differences between the countries.

I think it's the same with programming, the size of your program doesn't matter but the culture does. If don't use any system to develop, test,.. and don't really care about good code you will have bugs. On the other hand, with a good system you will have less bugs.

If the argument of the blog post was true, then you would have more bugs if you use more libraries? Or the bigger the libraries you use the more bugs? Doesn't make any sense.

There've been a lot of road safety and speeding restrictions introduced in the UK over the last 20 years, and at the same time there's been a drop in the number of deaths back to 1926 levels. I'm willing to bet that the profile of car ownership is very different to then.

http://www.bbc.co.uk/news/10408417

This analogy becomes more and more true as programming's virtues shift more toward communication and away from cleverness. When performance becomes a commodity (and it will soon, even for very large systems), the biggest expense isn't getting from point A to point B, it's the accidents that happen along the way. There couldn't be a better analogy demonstrating the need for programmers to write for humans rather than computers.

This is not necessarily true though. You might be better off writing code than figuring out how to use somebody else's half written library.

Productivity should strictly be number of hours between problem and solution.

Neat analogy. Just as I value concise code, I prefer cities that have fewer cars in them.

What would happen if driving drunk became legal? Nothing? That seem extremely counterintuitive.

One potential analogy: If drunk driving were legal, drunk drivers wouldn't drive as quickly because there is less risk of being pulled over. Driving more slowly with the impaired reaction time is theoretically comparable to driving quickly with normal human reaction time.

Would you drive drunk frequently if this became legal?

"drunk" is a loaded term.

Note that the different countries on that graph also have legal blood alcohol limits differing by factors of at least 4. Yet that is not reflected in the death rates.

While I do not feel safe driving at the U.S. legal limit, I do feel safe driving over the Swedish legal limit (which is 1/4 the U.S. one). While I wouldn't do it in the US, I would in Sweden.

That's not really what it says. Presumably Smeed's law does not hold up in the face of dramatic qualitative changes like that - but that doesn't disprove it in a practical sense since driving drunk is illegal in nearly all countries (presumably all that are sampled on that graph?) and isn't likely to become legal.

See my other comment: The legal limits in those countries differ quite substantially, so what's legal in one is not in the other.

oddly enough, not really.

The argument is that if drunk driving became common (because it was legal) then other drivers and pedestrians would adjust their behavior according to the increased risk.

Based on that, you would expect a spurt of additional deaths early on, as we adjusted to the new risk, and then the numbers would drop again.

That sounds pretty reasonable to me, certainly if I knew that every third driver was drunk, I would behave differently on the roads (ie, would never go near them).

Adjust your behavior to a car flying at you at 80MP/H? Right. And you do realize that drunk drivers don't need any other traffic to park themselves into a tree?

It's the same when gunloon rednecks argue that if it wasn't guns, it would be knifes, all the way down to a paperclip.

Not just behavior - environment too. In a world where drunk driving was common and legal I would expect fences by roads, pedestrian safe tunnels, warning lights, and other such features.

You are making the common mistake of changing a variable in isolation, without taking into account all the things that flow from your change.

It's reasonable. It would be so dangerous to be around traffic that other people would avoid it. Thus deaths might go back down, but note that there's nothing saying that everything else would be normal. It would for example be a lot more inconvenient for those that now stay away from traffic to get around.

These data should not be used to make the claim that attempting to increase safety is useless. Improved vehicle safety features, for example, has been compensated for by faster driving. That means the safety features didn't help lower deaths, but they did help everyone get around faster.

So if we want to make roads safer, we should make people think driving is more dangerous than it really is.

It's counterintuitive - changes in perception of reality are more useful than changes in reality.

How does that old chestnut go? "If you want to build the safest car imaginable, put a huge, sharp spike right on the steering wheel"?

> we should make people think driving is more dangerous than it really is

Which is precisely what is being researched and done in various areas, e.g by making the road appear narrower through various visual tricks.

And it works.

Until people learn. I don't mean by that that they necessarily know they're being tricked and consciously "undo" the trick, but they are then trained to handle a tougher constraint, and thus are able to routinely do something they could not before, out of pure training. The whole danger/constraint/learning system is actually very elastic. The net result is that not only they end up driving at the same speed as before in the modified area, they actually drive faster than before in the other non-modified areas.

People have a desire for mobility, and are very irrational. Danger does not necessarily deter, said I, enjoying my cigar.

Based on that, you would expect a spurt of additional deaths early on

Reply on news.ycombinator.com