Why isn't software as reliable as a car? [closed]

Question

I had a user ask me this question. We know that cars break down, but that's because of something physical (unless software is involved!).

I tried to answer that software is a much younger industry, but the user countered with "didn't the automobile industry become much more stable than and reliable with less people?".

I also tried to answer that software is more complex, but the user countered that there are many thousands of parts that make up a car. People that design and build cars generally just know their component(s) very well, but they still all end up working together as an end result.

So, why isn't software as reliable as a car?

Answer 1

The premise of your question is simply incorrect: Software isn't "less reliable" than a car. There are billions upon billions of devices out there that run embedded software 24x7, for years on end, with no problem. Heck, some of it are in cars, and control/monitor the engine. So, how can software be less reliable than a car, if cars themselves rely on software?

Answer 2

I design software and mechanical parts.

It is complexity.

Because there are millions of "parts" in modern software.

Software parts are very complicated and have a lot of STATE. A mechanical non-moving part has no state.

A mechanical moving part has its position (one variable).

A program that is running and uses 1Mb of RAM has a million bytes of state. That's far more state than any normal mechanical system.

There will be combination of states that never get tested because they happen so rarely. In a mechanical system (like a car) it is easy to check that mechanical parts do not hit one another during operation. The mechanical CAD software I use at work does it automatically.

If you built machines from invisible, non-touchable parts, and had millions of moving parts that all just missed one another, it would be like a simple program.

Even "hello world" runs on an operating system. The old 8 bit systems and minicomputer operating systems were pretty reliable because they were simple.

Things like DLLs and shared libraries get replaced as part of virus updates or software installs and then the program of interest doesn't work. Bit like changing the tire on your car for a bicycle tire. Some of the edge states of the library function interfere (don't act the way the program expects).

Programs written in languages like Java that don't allow many un-designed interactions between objects (pointer reuse, array bounds overflows) are generally pretty reliable once you get them to work at all.
When you use operating systems with static libraries, once a program works it just keeps working (but will still have lots of edge conditions, based on its state size).

Dave Parnas writes about getting reliability in software by making the state of the program smaller. The strict functional programming guys are doing the same thing by forcing single static assignment.

Answer 3

It's a matter of consumer choice.

If consumers demanded software to be as reliable as my Honda Civic (as opposed to my old Ford Maverick), it would be. Some organizations demand software that reliable, and they get it, typically for embedded software, sometimes for safety-critical things like space missions and air traffic control. The software still isn't perfect, but neither are cars.

However, customers demand other qualities in their software, and mostly aren't willing to pay for software that's possibly less functional, certainly more expensive, and ships later just because it's more reliable.

Answer 4

there are many thousands of parts that make up a car.

If only a computer (and the associated software) was that simple.

The computer has what a gigabyte of memory? Billions of flip-flops? A terabyte of disk? Trillions of "moving" parts?

The software may have 10s of thousands or 100s of thousands of individual lines of code running. Plus that many (or more) in unit tests and tools.

No. The "cars are complex, too" argument is bunk. Software is much, much, much more complex than a car.

Answer 5

The principles that make combustion engines work, and all the components that make up a car hasn't changed much in the past century. Sure there's been evolutionary improvements and hybrid cars, but the basic components are the same. You have an engine, a drive-train, etc. Even concept cars and your super expensive extremely fast Bugatti Veyron is built with the same basic structure. In short, designing a car is a well known problem.

Contrast that with developing software.

• Customers don't know what they want when they start. They begin talking about a luxury jet, but then when they realize the costs they want you to build it for the cost of a foot powered scooter.
• Car design takes years to get from idea to concept car, and more years to get from there to manufacture. When was the last time you had that luxury with software?
• Car parts are cast pieces of metal, but software components can change shape and interface often.
• The manufacturing process is completely different. With cars, the pieces are manufactured in mass quantities and the same pieces are used across different vehicles. With software almost everything is hand crafted because otherwise stuff just doesn't fit.

In short, there are a number of reasons why a car would be perceived as "more reliable" than software. I just came up with a couple.

Answer 6

Cars are reliable. So is most software.

But...custom cars, and custom software, both have their issues.

Any real car enthusiast, who has his modified 1970 muscle car, tinkers, and tweaks, and has break downs, and all kinds of stupid issues he wouldn't have had if he'd left it original. But...then he wouldn't have the supercharger...

Answer 7

Because the car you drive has been been made many times, the construction process is so refined that the same car can be made on a production line over and over again.

If it was a one-of-a-kind complex cutting edge car built from scratch once it would be nowhere near as reliable, for example look at how much higher the failure rate is in formula 1 racing cars. It's common for one or two to break down per race.

New software is always a once-off. What the programmers code has never been coded by them before. To get really high quality in this scenario involves a cost that is prohibitive for most products. Every non-trivial new software is effectively a prototype.

As an aside, this is one of the main reasons that applying traditional engineering techniques to software engineering is a disaster.

Answer 8

1. Car manufacturers get the entire spec nailed down before they produce the "final" product.
2. Automobile users don't tend to do stupid things that the designers didn't expect.
3. Cars are only "updated" once per year (typically), whereas most software is expected to be updated many times per year.

I could go on, but my browser feels like it's about to crash...

Answer 9

There's actually a very simple reason.

Software that makes money is software that garners market share. More often than not, the company that brings a piece of software to the market first will be the one that gets the majority of the market share, even if their software is not the best product in their particular market.

Consequently, the focus is on getting software released sooner and imperfect, rather than later and perfect.

Answer 10

I like most of the answers so far. Here's my spin on it.

The cost for failure is more severe for cars than software

Car failure could potentially cost a life. Even a non-life threatening vehicle failure represents a highly visible inconvenience to the user. Software failure just means some poor sap in production support will have to work overtime. And if that person is a full-time exempt employee, then gosh, it's not that expensive at all. In fact, poor quality and poor management are rewarded because free overtime actually reduces the per hour labor cost!

Of course, this depends on the kind of software being used (software powering weapons systems, avionics or medical systems could also have an effect on lives), but a car costs a good deal of money and is used regularly enough that lapses in reliability are quite tangible and painful. Software failures often have workarounds.

Another thought: Cars seem reliable but they have definite maintenance costs that are ongoing even if the car is functioning well, and culturally, this is accepted and even a prideful expenditure by people that care about their vehicles. Software on the other hand, is often already broken when installed, and often has to change over time, but culturally, no one wants to pay for maintenance.

Answer 11

Well, cars were pretty unreliable for most of their history, and there's definitely a learning curve. Cars have been produced on a large scale for about 60 years, whereas software's only been produced on a large scale for about 20-25. By large scale, I basically mean large enough the masses buy/use it and there's truly huge incentive to figure out how to perfect the procedure for creating it.

Answer 12

I like to think of the Car as an application. While the OS is the road on which the application runs.

The interface between road and car is well defined. Well tested and is extensively checked for backward compatibility (which is easy as the interface is simple). But even so you have some backward compatibility issues. Cars of type "Farrie" have a hard time running on roads of type "mud roads".

Even so you OS just like roads need constant maintenance. Bridges ware out. Cars put on snow chains and tear up the roads like application corrupt and damage the disks and files used by the OS.

Applications will be written on one OS. But in general they must run different versions of the OS (different types of road). So your supper optimized app may run smoothly and with no problems as long as it is run on the correct OS (Highways), while other general purpose (simpler) code will run fine on all types of road.

The Interface between Application and OS is defined but exceedingly complex and always fluctuating slightly. Especially since we allow the user to modify their own OS with extensions. If the government allowed users to modify the roads there would be a lot more crashes.

When you start limiting the ability of the user to modify the OS the reliability of the applications can become nearly rock solid. Look at all those embedded devices. We don't let users near their OS and thy run fine and continuously 24/7 without interruption.

So I would say it is not that software in unreliable. It is more like saying that the users is out digging holes in the highway for the applications. Hey your application just crashed into the hole I dug last year and forgot about.

Answer 13

First, your user needs to know that there is software so reliable in this world that he's not even aware it exists. Have you ever seen a TV crash? Me neither.

I think the main reason is that software is immaterial. Being immaterial means that non-developers don't see the progress going on. For instance, if I was making a car, you could see me assemble the different parts and it would look more and more like a car; however, if you look at me programming, maybe I'll spend hours cursing at a black screen with green text doing weird patterns and then suddenly when the pattern changes just a little bit I'll overexcited.

Because of that, normal people don't realize the complexity of software. When they see a window, they think they see the program as a whole, which is oh-so-wrong.

Also, software is much, much more often heavily customized than cars. When you customize a car, you won't go against its design because that would be visibly stupid. If my engine is in the front of the car, moving it to the back will most likely be a huge disaster. However, since software is immaterial, if the client asks you to do something completely against the design, they'll get no indication (except you, but they won't listen) that what they're doing is stupid, and then they'll go all surprised that it doesn't work as expected.

Answer 14

1. Lack of Information Sharing (programmers fly solo or in small groups -- car designers work with interconnected teams inside a large corporation, and they all share their knowledge; if we all worked for major corporations, we'd all be better programmers due to learning from others; this is also why things like open-source programs and online resources are very important)
2. Expectations of Field Entrants (it's ok if a car designer is only marginally useful for the first 5-10 years, but if a programmer goes into an interview and says he/she won't be of much use for 5-10 years, the interview is over)
3. Lack of Penetration Testing (due to lack of funds, legality issues, etc.; car manufacturuers, however, slam car after car into a brick wall, have wind tunnels, have relatively straightforward performance requirements, etc.)
4. Information Transparency (you don't know how most software works; you guess or you make assumptions based off interviews, press releases, advertising, etc.; with cars, however, the majority of stuff is right there for you to look at)
5. Inherent Encapsulation of Knowledge (the guy/robot welding the frame together doesn't need to know the mathematics behind the stability control system; programmers have to be knowledgeable about thousands or tens of thousands of things unknown to the average person, whereas car designers only need to know hundreds or thousands)
6. Tangibility (it helps when you can see it)
7. Age of Field (vehicle design is thousands of years old; motorized vehicle design is over 250 years-old [steam engines, etc.])
8. Criticality of Subsystems (cars will still "work" even if a lot of their parts stop working -- power locks, power windows, HVAC, windshield wipers, broken windows, lost hubcaps, flat tires [put on a new one], radio, a light or two, remote entry, etc.; when something on a computer breaks, it is often a SHTF scenario)
9. Interdependency (when one computer breaks, it isn't rare that it affects hundreds or thousands of other computers; when one car breaks, it is somewhat rare that other cars are affected -- if other cars are affected, it is almost always only 1-3)
10. Blanket Blame (if one part of a computer or one computer out of thousands breaks and hurts a system, the blame extends to the entire computer, or in the latter case, the entire network of computers; if your car is struck by a car with failed brakes, or if a car stalls and won't restart on the highway, only the individual car part is blamed)
11. Finite vs. Infinite systems (cars can only have so much packed in, and they are only expect to work under limited conditions -- e.g. you don't drive a BMW over terrain that only a Jeep-like vehicle can do; with computers, however, the possibilities are de facto infinite -- there's new stuff all the time, new APIs, new OS's, new security holes, iPads, mobile phone software, new this, new that, etc.)
12. Scope of Required Body of Knowledge (a person with a 130-140 IQ could learn almost all there is to know about cars, but could only learn a fraction of what there is to know about computers & programming)

Answer 15

The simple reason why the entire logic is flawed:

Mechanical devices can be simply reduced to Input/Output; increasing the number of parts to achieve this I/O operation does not change the I/O operation. Thus the system can be fully comprehended.

Software on the other hand has Input -> Process -> Output. Due to this nature the system can not be fully predicted or understood.

Donald Rumsfeld said it best:

“There are known knowns; there are things we know we know. We also know there are known unknowns; that is to say we know there are some things we do not know. But there are also unknown unknowns – the ones we don't know we don't know. ” —United States Secretary of Defense Donald Rumsfeld

In Summary:

• A mechanical device is a system that has known, and known-unknowns,
• Software has the above but also unknown-unknowns.

Answer 16

This is a stupid question (not from you, but from the original person).

This sounds like my father (a mechanic) that hates computers yet spends all day on eBay.

It's like asking "Why is a tree more reliable than a moth?".

First of all, I own 30 (yes, 30+) computers and not one of them has been in the shop. I just spent $1400 on my car in repairs. Go count the number of auto repair shops vs computer repair. Once again, stupid analogy.

Cars are made out steel, computers plastic. Cars work in all weather conditions, computers designed for indoor use.

My Commodore 64 (26 years old) works perfectly and has had no repair. Both of my vehicles (less than 10 years old) has had very extensive repair. Show me a car with thousands and thousands of hours of use that is 26 years old that still runs 100% the same it did when it was factory new.

Answer 17

Software is based on bits: 0 and 1. Cars are based (mostly) on mechanical parts.

A mechanical part can wear out or malfunction and still kind of work. Your brakes get worn, or a valve gets leaky, but the car still mostly works until you can get it repaired.

Software, for the most part, doesn't have such a thing as gradual failure. It either works, or it breaks. Dividing by zero isn't "almost correct"; it's just an error. When you try to save to a drive without enough space, you can't squeeze hard to force all the data in; it just won't go.

I don't think software is necessarily less reliable than a car, but when software fails, it fails immediately, not gradually.

Answer 18

I think I've got a much better analogy. Take a company that builds ambulances to customer specification. The base platform (say, a fully operational and street-legal RV-cutaway chassis) requires modifications at several points: frame, charging system, filler spout, suspension, etc. Those modifications not only have to be street-legal but meet jurisdictional requirements while satisfying customer desires.

Then you have to build the ambulance body itself, which is also fraught with regulatory requirements from several layers of government and other bodies. While still satisfying the customer desire for some funky seating arrangement or storage system. And don't forget that you have a hundred different customers from around the world all on different purchasing and deployment schedules, none of whom ever says "I'll take a dozen more just like the last one" without also submitting pages of exceptions that frequently require a full re-engineering of the whole thing.

Cars? That's trivial. You'll buy what's built and you have no direct impact on any aspect of the design. Even your choice of colour is artificial because you can't actually specify something that hasn't already been engineered and tested. There is in some sense only a 'market' not a 'customer'. I would argue that off-the-shelf software produced for some market is generally as reliable as the car you pick up at the local dealership.

Answer 19

Cars aren't actually as reliable as you think. It's just that faults can stay hidden for a long time (or ignored) without causing the whole thing to fail. Your car leak oil and/or coolant? No? Are you sure? You're probably wrong... It's probably just leaking a very small amount somewhere that you haven't noticed yet... Now extend that to the suspension, body panels, interior, etc. I don't think I've ever yet encountered a car that I couldn't find something wrong with. However, the vast majority of the parts are superfluous to the mission of transportation. Not so with a computer. Nearly every part in a computer is critical.

It's the old analog vs. digital debate, just repackaged. Digital TV is great, as long as everything is perfect. The instant something goes wrong, the audio stutters and the video blocks out making it useless. Compare with analog TV where you'd just get a little hiss or static that's easily ignored.

Answer 20

Firstly of course some sw is perfectly reliable, and cars - especially British and Italian ones - are not necessarily that reliable.

That said my experience of working with automotive software is that it comes down to two things:

• Warranty costs. When your sw fails you restart it. Perhaps you will file a bug report. Or use the expensive support contract. When your car fails you will bring it in and demand that it is fixed under warranty. This will cost the maker $100 and up. If each sw failure cost the maker $2 I am quite sure sw would be more reliable.

• JD Powers (and other quality rankings). JD Powers surveys ThingsGoneWrong (which could be anything). And if that ranking is really bad people will simply not buy your car, at least not for enough money to make a profit. If we had a JD Powers for sw and people really cared about it, then I am quite sure sw would be more reliable.

So if you make unreliable cars, warranty costs will quickly eat up all you profit and in a few years bad quality rankings means you will not sell any cars at all. If you make unreliable sw then the users will complain and you get to sell expensive support contracts.

Answer 21

Motor Vehicle reliability and safety is mandated. In many (most?) countries it is required by law that they have a minimum level of reliability and safety and they are tested for the worst-case scenario (whatever that is). Commercial software is not, for the most part.

While there are other legal implications for software, it is important to note that if the software crashes everytime you press the "Save" button, then this is simply a matter of a patch/fix and then you keep going. If a car crashes every time you turn the indicator on, then this is a much worse thing. It's simply not so important for Microsoft Outlook to run without crashing unexpectedly as it is for an SUV to run without crashing unexpectedly.

That being said, there are other pieces of software that have as much or more responsibility than the mechanics of a car. Airplanes and Missile Guidance systems have to be reliable; there are lives at stake! One would hope that these are more stringently tested than the average motor car.

Answer 22

The car industry do not release a "beta" car to the public for testing, the car industry do not have to worry about the environment in which they deliver their products either, however they I have to worry about many other things.That is to say that the software industry are first fundamentally different (as we all know) so reliability and complexity are really suggestive. In my opinion a car as complex than a software but it is easier to see what's working or not since

• At the bottom of cars are not virtual, it is bound to be easier to test (but more expensive)
• They started much earlier than the software industry, even if they were fewer people, you can't minimize the practice and knowledge they gathered. The software industry is still a baby compare to it.
• All of the car industry are bound by law and ethics not to make car which kills their driver especially those last decades.

So the statement saying that software is less reliable than cars, can be true for many kind of software and completly wrong for other area (security, aeronautics ...) you can be sure that a software is at least most reliable than the most reliable of cars in those area. Simply because those area are critical and from what I know only in those area software can compare to the car industry.

Which leads us to this : most software are not considered to be critical in their domain. When it is considered as such, you have reliable software, the only problem you will find on those are problems linked to the environment (so if you can control it though, virtually you'll have no problem), not the software itself. However most software editor do not work in these critical area, of course they are bound to provides a certain level of quality but they are more bound (in my opinion) to deliver the software as soon as possible. However good software requires : good project management, solid specifications, good design and good level of skills from those working in it (to resume it). That is just to make it, we are not even talking about selling it...

All of this takes time and so requires money. I'm not saying you get what you're paying for what I'm saying most of the time you produce what you invest for never less (except if you got screwed but then you produce nothing so ...) and sometimes more..

Answer 23

I don't believe cars are less complex. But even if that's the case, I don't think that software is less reliable. However, I believe there are more important factors that lead to discrepancies in reliability of software:

1. Abstraction involved in Software. This causes software creators misunderstand how things are really working. As time passes, more and more abstraction is added. For example, Assembly language gives you direct control to the machine. C is more abstracted but still close to the machine. Java, C# and what will come next are heavily abstracting what happens in the machine. Another example is if you are a programmer who wants to understand how networking occurs on the software level, then you should know to program with C because the infrastructure (as a software) is written in C.

2. Different Experiences and Knowledge of the makers leads to Different results. Different Developers create software with different reliability. The same can be said about Car makers. However, the difference is that any one who can use an editor and a compiler or even simply install an IDE (Integrated Development Environment) can create software And for free. To make a car, you need a huge investment, a factory (some can make a car without using one but you'll not find it around you everywhere). The fact that you'll put a huge investment, means you'll try to hire the best in the field. Yet, there is still reliability issues with cars. If you are aware of it, many millions of cars are being withdrawn from markets for serious [bugs]. In my car, the manufacturer will replace the brake clippers for free for all cars bought in the same year. This is a serious issue and in my opinion shows that even cars are not as reliable as your client says.

3. Bugs in software usually are more appearant to users than cars. This is the result of interactivity and response between the user and the software. In a car, we pay attention to fewer details like "The car is accelerating when we step on the gas pedal", breaking, turning, lights, mirrors, ... etc. In software, with every user click/input there is usually a response. So, there are many points where the software can be buggy and the user will notice it immediately. This makes a user believe that it is less reliable than cars.

4. Hacking And Attacks. The more widely a software is used, the higher the percentage it will be under hacking attacks. You can compare this to car theft. To me also a car reliability is compromised when it can be opened by someone other than it's owner or key. However, it's easier to try to attack software than a car since the attacker is not visible. So, when a software is compromised, people associate that it is not reliable even though it is reliable in what it was made for.

Answer 24

It's like everything else... when it works you don't care... when it's broke (or doesn't work the way you want/expect) you care.

Think of airplanes. Tons of people are worried about people trying to hijack or blow them up. But really the number of negative events is tiny compared to the number of daily flights. (There are more flights in one day then have ever been hijacked or bombed.. heck even attempted to be hijacked or bombed.)

It's all in were you look and how you measure.

Answer 25

It's actually quite simple. Cars are old tech. Sure there's bells and whistles these days (that break) but if you look at early cars - they broke a lot.

The 'technology' behind the mechanical parts of cars have been around for hundreds of years and the internal combustion engine has been around for a long time too, and when they were introduced, there were lots of problems.

Consider that memory problems are almost a thing of the past with some of our managed platforms. Give software a couple hundred years and we'll have it nailed down too. In fact, considering the complexity of software, I think we're ahead of the curve.

Answer 26

Modern cars rely on s/w. When modern cars fail, for example the engine computer fails, its usually (though not always, but usually) the electronics thats carked it, not the s/w.

Ask any owner of a modern car with an ECU in it how long its run before an expensive failure. I'll be stunned if you get 10 years. Modern cars full of electronics and sensors are stunningly unreliable.

If you study reliability theory the answer becomes blindingly obvious. Everything mechanical (expect software) has a steady-state reliability which is the failure rate when outside the infant-mortality and wear-out regions. The failure-rate of the end-item is the SUM of the failure rates of the parts. Add more parts: aggregate failure rate becomes a higher number. The challenge then is to get the failure rates of all those components really low.

When it comes to things like timing belts and cylinder wear and oxygen sensors getting full of crap, and connectors going ohmic, and wires breaking due to vibration - there are techniques that can be used to reduce the failure rate. The cost also goes up as you do this.

Software, on the other hand, has a constant failure rate. In spite of the difficulty of finding defects at times, in the end all software is a sausage machine. Inputs -> Do stuff -> Outputs. Sometimes the ORDER of inputs and the combinations of inputs leads to failure with modes that are detectable. When that happens you've found your defect, you fix it, and you move on.

Software that has no (known) defects has effectively a failure rate of 0. It will run forever without failure. (Mean Time Between Failures = 1/failure rate). The hardware platform will fail first.

Software with defects might run only until the right combination of input conditions, over time, causes the defect to become manifest.

The FALLACY in all this is to try and compare failure rates of physical things (caused by wear, metal migration in IC's, ingress of water, vibration, etc) with a failure rate of what is essentially a finite-state machine which simply does exactly what its instruction sequence tells it to do.

(Even things like alpha-particles flipping bits in RAM is a physical phenomenon, not a software defect. The manner of handling such an eveny MAY however be a software defect, but remember, that nasty alpha particle was just another input to the software.)

Answer 27

The difference between software and cars is that in order for software developers to maintain sanity, exact duplicates of software must be driven by all users of the software and in order for automobile manufacturers to maintain sanity, they must accept that all their users will be driving significantly different cars because the way you drive a car changes the car, but the way you use software doesn't necessarily change the software.

On the other hand,

If you had some way to check the oil in your software, you'd know when it was going to fail.

If you had some way to change the oil in your software, you'd probably be able to extend it's life by a few months.

And to pointlessly extend the analogy:

Patches aren't changing the oil, they're replacing a leaky gasket.

Updates aren't changing the oil, they're fixing the brakes.

Releases aren't changing the oil, they're more like adding a key-less ignition.

Answer 28

Cars that break down are not tolerable. Also it can endanger lives. Software that breakdown are tolerated, and users work around it or just accept it. There isnt much of a demand for bug free software.

Also software tends to be customized, you dont have 10000000 different models of cars. I'd say wikimedia is reliable and tons of ppl use that software. So you could say a lot of people do use bugfree or reliable software. (wordpress, various source control, mysql and sqlite are pretty reliable, etc)

Answer 29

Softwares are mathematical and logic objects, while cars are real objects.

Furthermore, you can easily know when a car has a problem and what is the problem, while it can be much more difficult with softwares: imagine someone having a problem with a computer and someone having a problem with a car; this person can better know what's wrong because cars are less abstract than computers.

I'm not saying computers are harder to understand: cars also involve a lot of physical laws such as thermodynamic, electronics, chemistry.

You could also extrapolate this comparison, saying: "why a hammer is more reliable than a secretary ?".

I don't think the question is really relevant, but I think it shows really well how a lack of a good mathematic education can affect the understanding of a certain kind of system.

Answer 30

Software is a lot more complex than a car, even if the car is composed of thousands of components.

If a car was as complex as software, then all the components of the car would depend on all the other components of the car, and many car components would be directly linked with many other car components.

All the world's cars barely equal the original Unix software in complexity.