65

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?

Thomas Owens
  • 79,623
  • 18
  • 192
  • 283
Alex Angas
  • 681
  • 1
  • 8
  • 19
  • 29
    Which car? Some are much more reliable than others. – Zoot Jan 28 '11 at 22:18
  • 244
    If somebody was almost done assembling a car when their boss came over and says "oh hey, the customers would like us to attach a jet engine to it, can you have it done in a couple days?", cars would be pretty unreliable too. – Adam Lear Jan 28 '11 at 22:23
  • 3
    Well... because cars, being physical objects must break sooner or later. Software is not bound to physical constraints, so its more reliable. – Mchl Jan 28 '11 at 23:00
  • 3
    For a second I thought this was going to be that old joke about how if Microsoft designed cars we'd have to close and reopen the windows every time the engine stalled. – Travis Christian Jan 29 '11 at 00:13
  • 28
    Software is reliable. It's just the big enterprisey software that isn't. Have you ever seen a TV crash? Me neither. – zneak Jan 29 '11 at 05:30
  • 19
    There are laws to enforce **learning to drive** before being allowed to drive a motor vehicle. Additionally there are many courses on how to drive that are targeted at the under-educated so that they don't crash. There are no such programs for **learning to use a computer** and as such, the under-educated populous crashes with regularity and blames it on the programmers. – zzzzBov Jan 29 '11 at 08:09
  • 14
    Just compare number of injuries caused by software and by cars, and you will see that software is far more reliable than cars. – mouviciel Jan 29 '11 at 09:24
  • 2
    @zneak - not the TV, but the cable box crashes every couple of months; @zzzzBov I give you the [European Computer Driving License](http://www.ecdl.com/) – robertc Jan 29 '11 at 11:14
  • 1
    "Last month automaker Toyota announced a recall of 160,000 of its Prius hybrid vehicles following reports of vehicle warning lights illuminating for no reason, and cars' gasoline engines stalling unexpectedly. But unlike the large-scale auto recalls of years past, the root of the Prius issue wasn't a hardware problem -- it was a programming error in the smart car's embedded code. The Prius had a software bug." – Amir Rezaei Jan 29 '11 at 13:56
  • 1
    @robertc, I think that a TV and a cable box, from a functional point of view, do two vastly different things. – zneak Jan 29 '11 at 17:52
  • Just try programming in a language like Haskell. Pretty soon all the code you write, even on the spur of the moment will be pretty reliable. (Unless you have made some glaring logic errors) – Robert Massaioli Feb 03 '11 at 03:47
  • 8
    A car has at most a few hundred moving parts, while even a simple software program has billions of "moving" parts. – Christoffer Hammarström Feb 03 '11 at 09:13
  • @Robert Massaioli - Haskell might let you make minor logic errors but users won't. – JeffO Feb 03 '11 at 18:35
  • 4
    $500 can get you pretty good software, but the car will be a POS. – JeffO Feb 03 '11 at 18:39
  • 1
    What evidence does this person have that suggests cars are reliable? According to him I guess I didn't just take my car to the shop to have the heat fixed. And sometimes I have trouble starting my car when it's extremely cold. I think it's pretty dumb that he acknowledges that cars break down, but he ignores it anyway. If cars were reliable, my car should last me 100 years at least right? – jonescb Feb 03 '11 at 21:30
  • @Jeff O That is true but atleast you only waste your time solving logic errors and not syntax or runtime errors. – Robert Massaioli Feb 03 '11 at 21:55
  • Actually, according to John Carmack making software is more complicated than making space probes and launching them into space. – EpsilonVector Feb 05 '11 at 12:43
  • "If cars had followed the same developmental path as computers, a Rolls Royce would cost $100, get a million miles per gallon, and crash once a year." – Craige Mar 03 '11 at 16:18
  • 3
    @AnnaLear's answer just defers the question anyway — the next obvious line of inquiry becomes, "why don't programmers have a tendency to refuse late changes, poor specs, etc." And then you start getting into the real answers, like commercial pressure, trade culture and customer priorities. – detly Oct 21 '11 at 00:47
  • 1
    I don't think "reliable" is the right word to use in this question. Software is 100% reliable. It will behave the same way every time. Cars are not reliable. They degrade over time. When a computer system breaks down, it is either due to hardware failure or bad software design. The software never "goes bad". – Wolfger Dec 08 '11 at 17:04
  • Because most software is implemented in languages designed in 1970's that don't have any kind of verifiability without a large amount of effort. Ada and derivatives are used in aviation quite a bit as well as specifications and formal proofs. Software *can* be as reliable, it's just the tools aren't there to make it easy. – nwmcsween Feb 04 '11 at 02:38

31 Answers31

182

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?

apaderno
  • 4,014
  • 8
  • 42
  • 53
GrandmasterB
  • 37,990
  • 7
  • 78
  • 131
  • 9
    +1, also software can be _perfectly_ reliable (in mathematical sense), while a mechanical device can never be (as the notion of reliability here is different -- i.e. it is about giving a _practical_ guarantee that everything will work and not break apart or wear at some moment). – mlvljr Jan 28 '11 at 22:48
  • 9
    +1 for pointing out the fundamental flaw in the question – Gary Jan 29 '11 at 09:25
  • 1
    I would add that I have never seen a car in the space, while I have seen software up there... – Matthieu M. Jan 29 '11 at 10:47
  • 1
    -1 -- the software that runs on the "billions upon billions" of embedded devices are each individually generally relatively trivial in comparison to the more fault-prone, highly stateful, broad software that the question is surely referring to. This is really only a partial answer at best, a red herring at worst. – Rei Miyasaka Jan 29 '11 at 21:40
  • The Bluesmobile crashed really bad at the end... –  Feb 03 '11 at 12:45
  • The thing is, that almost anyone and his dog can write any kind of software overnight. While it takes billions and years of careful planning to produce a new car model. – LennyProgrammers Feb 03 '11 at 14:30
  • 5
    @Rei Miyasaka: Do not underestimate the level of complexity in embedded software. ;) – Mchl Feb 03 '11 at 15:53
  • 3
    @Matthieu M. - you never saw the Apollo Lunar Rover? – JeffO Feb 03 '11 at 18:37
  • 1
    @Mchl -- And the particularly complex ones are likely bug prone. – Rei Miyasaka Feb 04 '11 at 18:10
115

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.

Tim Williscroft
  • 3,563
  • 1
  • 21
  • 26
  • 12
    +1, just imagine a "mechanical computer" with gears, etc instead of loops and variables -- how complex (and unreliable) should it be just to "copy" a 20-40-... KLOC program? And let us remember why it was near impossible to build working mechanical computers, also ;). – mlvljr Jan 28 '11 at 22:41
  • 3
    +1 for mentioning virus updates which I suppose is an euphemism for _that-OS-whose-name-shalt-not-be-uttered_ – Trinidad Jan 29 '11 at 00:12
  • 1
    And mentioning Mr. Parnas in the context of software reliability probably should yield an upvote by itself. – mlvljr Jan 29 '11 at 02:51
  • 6
    You've mixed up apostrophe usage in almost every instance. A mechanical moving part has *its* position (not "it's"). *It's* complexity (not "its"). Things like *DLLs* (not "DLL's"). See also: http://english.stackexchange.com/ – Asherah Feb 03 '11 at 05:22
  • 2
    mlvljr: look up Charles Babbage and his analytical engine: http://en.wikipedia.org/wiki/Analytical_engine – Mchl Feb 03 '11 at 22:34
  • @Mchl Yep, but I was just trying to imagine Mr Babbage running a "Babbage Basic" on it -- and could not ;) – mlvljr Feb 10 '11 at 01:47
  • 1
    Artificially simplifying the mechanical system in order to argue that it's simpler is dishonest and unnecessary. Dishonest because a mechanical moving part does not only have "position" you must also worry about inertia (i.e. velocity), rotational inertia, temperature, or wear, all of which are persistent state of mechanical objects. If you let electrical (but non-electronic) components in you might also have energized capacitors and inductors, which again are persistent state. Unnecessary because even after taking all these things into account, the software is still more complex. – Ben Voigt Mar 03 '11 at 14:34
  • @ben you haven't got high-end CAD software like Solidworks premium. It takes me a minute to do a simple stress analysis. Temperature can be done similarly. I'm not arguing that mechanical engineering is easier, it isn't as all the points you raised matter. But a software system has so many more degrees of freedom/it's state space is bigger/the past state influences the future state in exceedingly complex ways. You can design a pretty good rocket motor with a slide rule. You can't write modern software without a computer. – Tim Williscroft Mar 03 '11 at 22:56
  • Can somebody provide a link to the David Parnas literature? – Jim G. Oct 21 '11 at 02:58
  • http://www.amazon.com/Software-Fundamentals-Collected-Papers-Parnas/dp/0201703696 – Tim Williscroft Nov 16 '12 at 23:48
  • I recently did some electrical power analysis for a military ground vehicle, 4 wheels. Much more complicated than a car (Two sets of lights for starters). has a number of unexpected failure modes, some quite nasty due to complexity. – Tim Williscroft Nov 16 '12 at 23:50
56

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.

David Thornley
  • 20,238
  • 2
  • 55
  • 82
  • 4
    +1 for this answer - none of the other answers even *matter* . If people *cared* badly enough about software being as reliable as cars (however much that is), **it would be**. But when a program crashes, you reboot your computer - when a car crashes, OTOH... – Cyclops Feb 03 '11 at 14:16
  • @Cyclops I agree, but I think it's worthwhile pondering why people came to have these different opinions on cars and software. And I think the main answer is that for a program to be *useful* to an average human being, it usually has to be orders of magnitude more complex than a useful mechanical device like a car. Many of the other answers address this. Also the *risk* of faulty software is usually low. – j_random_hacker Feb 03 '11 at 15:44
  • 2
    @j_random_hacker: I don't see that people have different opinions on reliability due to different complexity, because most people have no good idea how complex a car or program is. They have different expectations, because software has more problems than cars these days. They do care about consequences. A car failure is likely to strand somebody where they don't want to be, unable to go anywhere, and is likely to cost serious money to remedy. It is always inconveniencing and can be life-threatening. For most people, a software failure means some lost work. – David Thornley Feb 03 '11 at 16:17
25

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.

Garry Shutler
  • 641
  • 4
  • 8
S.Lott
  • 45,264
  • 6
  • 90
  • 154
  • 6
    Software looks simple only because we are very good at our jobs and make it look simple to the layman :-) – Martin York Jan 28 '11 at 23:00
  • 3
    actually cars ARE complex TOO. – Mauricio Jan 29 '11 at 00:31
  • 9
    @Mauricio: Never said they weren't complex. The point being that software can be several orders of magnitude more complex than a car. – S.Lott Jan 29 '11 at 01:43
  • @S.Lott : given the fact that every new car contains a bunch of software, there is something odd about your argument... – Joris Meys Feb 03 '11 at 13:06
  • @Joris Meys: It's not my argument. It's the OP's argument. Read the question for the specious "thousands of parts that make up a car" nonsense that must be countered. – S.Lott Feb 03 '11 at 13:37
  • @S.Lott : I reckon that 'Software is much, much, much more complex than a car' is your argument, no? Now as cars contain software, how can a car be less complex than one of its parts? sounds odd to me... – Joris Meys Feb 03 '11 at 13:44
  • @Joris Meys: There's a trick to this. It's called "abstraction". The software buried inside a carburetor is not a set of discrete lines of code that can be adjusted and tweaked. It's isomorphic to a simple, mechanical control. It cannot be observed in isolation or modified. The "software" in the OP's question (not in the real world, but in the question) is in-house developed application software, where the components and lines of code are observable and can be modified. The question itself is bad. Making answers difficult. – S.Lott Feb 03 '11 at 13:47
  • 2
    And the lines of source code in java or any other higher level languages translate in a far large amount of op codes that actually run on the CPU which in turn sends commands to dozens of support chips. You cannot even begin to compare the complexity of a modern software application to a relatively simple device like a car. – Jim C Feb 03 '11 at 14:07
  • @Jim C: Exactly. Also. For fun. Count the number of orders of magnitude from bits to terabytes and 100-nanosecond clock pulses to 168 hours of uptime per week. – S.Lott Feb 03 '11 at 14:56
  • 4
    Software is not any more complex than a car. Both cars and software naturally grow in complexity until they reach the outer limits of what people can manage. Computers may have billions of of elements, but many of them can be treated as ideal elements and they work similarly. That inherent simplicity is why software grows so massively complex: it grows until its difficult to manage. Whereas vehicle components have other elements of complexity: they have to deal with wear, corrosion, temperature fluctuations, etc. Both are highly complex, just in different dimensions. – whatsisname Feb 03 '11 at 15:09
  • @whatsisname: If they're the same level of complexity, why does software seem unreliable and a car seem reliable? – S.Lott Feb 03 '11 at 15:14
  • @S.Lott: because the amount of expected inputs and outputs widely differs. If you were trying to tow a 20,000lb boat with a Honda civic you'd get terrible unreliability. I'd say that compares to dealing with some massive excel spreadsheet with tons of VBA code. Few would try towing the boat, but people are regularly willing to push software like that. – whatsisname Feb 03 '11 at 15:20
  • 3
    With software it is easier to keep adding more software, then it is to add more mechanical components. While both are "organically" grown, software is growing much faster. – Jim C Feb 03 '11 at 15:20
  • @whatsisname: "expected inputs and outputs". I'm not sure that address the question -- as asked above. However, if you think that it's the way they're used, not an inherent feature, then provide your own answer. – S.Lott Feb 03 '11 at 15:46
  • @S.Lott: it's entirely in the way they are used. How about instead of a car we look at an airliner. Are those not massively complex devices? One could land in a 100F desert, take off and soon be in the atmosphere at -50F, then land again in snow with no visibility. Now, imagine how reliable that airliner would be if you never performed any maintenance on it. It would not be long until it fell out of the sky, and would be 'as unreliable' as software. Both software and mechanical systems can be just as complex; it is how we deal and interact with them that gives the perception of reliability. – whatsisname Feb 03 '11 at 15:54
  • @Jim I think you're onto something there. One of the distinguishing characteristics of code is how easy it is to add features. With a car, you know at the outset that there's only so much room under the hood. – j_random_hacker Feb 03 '11 at 15:56
  • @whatsisname: I don't agree. It's inherent in the structure. Pick anything you want that's mechanical. Compute the orders of magnitude from small to large parts. Compute the orders of magnitude of time from shortest design feature to longest service life. Software seems to win the orders-of-magnitude count. Please post your distinct answer as a distinct answer. – S.Lott Feb 03 '11 at 15:57
20

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.

Berin Loritsch
  • 45,784
  • 7
  • 87
  • 160
  • 6
    Correction on manufacture: software manufacture is trivial. This leads people to think of some aspects of programming as manufacture, whereas programming is all design. Every program is a new design. – David Thornley Jan 28 '11 at 22:39
  • 1
    Every program is either new -- yet to be proven -- design or a faultless download of existing, proven software from a reliable digital library. A big dichotomy there. – S.Lott Jan 28 '11 at 23:02
19

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...

CaffGeek
  • 8,033
  • 5
  • 32
  • 38
  • 3
    nitpicking: most (visible) software is custom software. hence the perceived state of general unreliability. – Javier Jan 28 '11 at 22:36
  • 4
    @Javier, I would think most visible software is the off-the-shelf stuff that you can buy at an office supply store, or that come with your computer. – Marcie Jan 28 '11 at 23:26
  • 1
    @Javier: Custom software, by definition I would think, is designed/made for a specific audience - not the general public. – Steven Evers Jan 29 '11 at 00:00
  • @Marcie:even if windows, office and photoshop are everywhere, every business has its own customized accounting, and processes system. Also think of every website out there, if it's not wordpress it's custom. – Javier Jan 29 '11 at 08:59
  • 3
    @Javier, not every business. Many just use off-the-shelf products. – Marcie Jan 29 '11 at 12:15
  • Do you have any idea how many embedded programms are out there? I every car, TV, DVD player, phone, washing machine, microwave oven, toaster etc. This is neither custom nor shelf software. – EricSchaefer Jan 29 '11 at 18:15
16

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.

Alb
  • 3,359
  • 2
  • 20
  • 24
  • 1
    +1 Building a car is not the equivalent of building a software program. Building a car is more equivalent to *running* a software program. Designing and speccing a car is more equivalent to building a software program. And there are tons of problems during car design that get ironed out along the way, just as with software. – RationalGeek Feb 03 '11 at 13:41
  • 1
    I disagree with this statement: "As an aside, this is one of the main reasons that applying traditional engineering techniques to software engineering is a disaster.". Software development definitely involves engineering principles: Reusable components, composition, stress testing, building blocks etc – Philluminati Feb 07 '11 at 12:42
13
  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...

Glen Solsberry
  • 211
  • 1
  • 11
  • 3
    Automobile users do plenty of stupid things, including things designers didn't expect. Thing is, there's only very limited inputs, and there's no specific expected results for putting eye liner on while driving that are different from reading the newspaper while driving. – David Thornley Jan 28 '11 at 22:42
  • 10
    @David Thornley: Just imagine if people expected a car to work like a computer... "I was reading the paper while driving, and now the headlights doesn't work any more. Perhaps it's related to the steering wheel that I removed to make place for the newspaper, so I ran into a wall. The safety belt protected me just fine, but it didn't protect the headlights..." ;) – Guffa Jan 28 '11 at 23:12
  • 1
    Yep, [drivers never do stupid things](http://i.telegraph.co.uk/multimedia/archive/00675/salisbury-double-pa_675900c.jpg) – robertc Jan 29 '11 at 11:05
  • 1
    @robertc You can't design for even that level of stupidity... – Glen Solsberry Jan 29 '11 at 17:01
10

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.

Robert Harvey
  • 198,589
  • 55
  • 464
  • 673
  • 2
    This only works if the 'best' person ends up not being that much better. If they are much better then you get what is happening with Apple now with them coming in late, with outdated tech, and still blitzing the field because they "just did it right". – Robert Massaioli Feb 03 '11 at 03:51
  • @Robert: Apple is a complete end-to-end solution (ITunes store), and I'm not sure I agree that their tech is out of date. If it weren't for them, we might all still be using those crappy slider phones. – Robert Harvey Feb 03 '11 at 04:12
5

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.

Bernard Dy
  • 3,188
  • 26
  • 33
4

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.

dsimcha
  • 17,224
  • 9
  • 64
  • 81
4

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.

Jim G.
  • 8,006
  • 3
  • 35
  • 66
Martin York
  • 11,150
  • 2
  • 42
  • 70
3

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.

zneak
  • 2,556
  • 2
  • 23
  • 24
3
  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)
Michael
  • 473
  • 1
  • 4
  • 12
3

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.
Darknight
  • 12,209
  • 1
  • 38
  • 58
3

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.

HLGEM
  • 28,709
  • 4
  • 67
  • 116
cbmeeks
  • 411
  • 1
  • 3
  • 12
2

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.

Kyralessa
  • 3,703
  • 2
  • 19
  • 20
1

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.

Saleh Al-Abbas
  • 83
  • 1
  • 5
1

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.

1

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.

Brian Knoblauch
  • 4,170
  • 1
  • 17
  • 20
1

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.

1

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.

Anthony
  • 605
  • 6
  • 13
1

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..

lollancf37
  • 281
  • 1
  • 3
  • 9
0

How many are there car designers? 10,000 top? - they are talented and they know what they're doing.

How many are there software programmers? 30 millions? - and many of them have no idea what they're doing, take for example PHP programmers, you can learn PHP and write your first program in less than a few hours.

If software was to be written only by 10,000 of the best programmers, then it would be as reliable as cars are.

Czarek Tomczak
  • 206
  • 3
  • 8
0

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.

Matthew Whited
  • 768
  • 7
  • 9
0

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.

Steven Evers
  • 28,200
  • 10
  • 75
  • 159
0

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.)

quickly_now
  • 14,822
  • 1
  • 35
  • 48
0

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.

Peter Turner
  • 6,897
  • 1
  • 33
  • 57
0

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)

  • 1
    There's plenty of software out there that can endanger lives if it fails. – Adam Lear Jan 29 '11 at 04:58
  • @Anna Lear: Yes, but he is talking about 'software in general'. All cars endanger most software does not. Also from what i know, that kind of software is often reliable –  Jan 29 '11 at 05:16
0

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.

jokoon
  • 2,262
  • 3
  • 19
  • 27
0

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.