Why cars crash less than software

Cars and Software

Anyone who has ridden with me in a car knows that I am not a slow driver. But I do know my limits, and the limits of whatever car I am driving. In used to drive professionally and have a very safe driving record. My car can go faster than I drive, but I do not push it to it’s limit. Is it because of speed limits? No, the police in Turkey frequently do not pay attention to such items, and in Germany on the autobahn I’m free to drive as fast as I like in many areas. What is the reason then? Well its very simple – at certain speeds and of course including factors such as weather, road conditions, traffic, etc, there is a rational speed limit at which above it would be unsafe to drive. What does this have to do with software? Don’t worry, I’ll get to that.

Let’s also consider the features of a modern car. It’s equipped with head lights, anti-lock breaks, seat belts, air bags, safety frames, and more. Why is this? Because the goal of the average car is not to go as fast as it can, but instead to provide reliable and safe transportation while achieving normal and prudent speeds. If you want a fast car, get yourself a Formula 1 car. But you better be able to drive it, and you won’t be able to drive it around town for normal use.

Why then is it then that so many developers focus on speed at the sacrifice of safety? Surely we do not want our software to run slowly. But if our software runs fast enough for the users needs (reasonable and prudent) then why make the software more likely to crash by turning off safety features? And what if our software did run a little bit slower? Think about this – if you ask your users this question. Which would you prefer? Software that runs a little slower but is still usable and comfortable (A family car), or would they rather have software that runs a bit faster but crashes more often? (A car without seat belts, air bags, anti lock brakes etc). Essentially we need to ask ourselves. What do our users really want?

Should software run faster,
or crash less?

Faster Engines, Same Drivers

Computers have gotten faster but in general most business software already ran fast enough. Now of course there are exceptions, games, compression, encryption and so forth. But what do most users do (aside from core gamers)? They use business applications. We should be using the extra power to ensure safety of the programs, not trying to make something run faster that already runs as fast as the user requires it. Do you really need that menu to paint faster? Engines have gotten faster and more powerful for cars too. We’ve seen modest increases in driving habits, but speed limits aside drivers still drive about the same speed they did before. If you don’t believe me, spend some time studying traffic statistics. Why? Because the cars already can go faster than the driver needs.

User Experience

Even with more safety features, most modern computers will have power to spare. So what should we as developers do with it? Improve the user experience. Put in more safety checks. That’s certainly a way to improve the user experience – don’t crash, and if you do at least don’t trash their data.

Make interfaces more intuitive, more real life. In fact, this covers a lot of the goals of Windows Vista. On older computers it has an interface like XP. On more powerful ones it has a richer more natural, more useful experience. Sure there is a lot of 3D and flash, but sit down and use Vista. These user interface improvements are useful too.

There is no such thing as a debug car

C++ Developers (And to be fair, any native code compiler user) are famous for making two builds. One for speed as they say it, and one for debugging. If a user crashes too much the issue them a debug build, or often the debug build is used for beta testing. However in their release build the developer often does not just turn off some of the checks (buffer overruns, etc) they turn off everything, or at least nearly everything. Would you drive a car with all of it’s safety devices removed? Not very likely. So why do we do it with software? And what good does issuing a debug build after a crash do for the user? If it were a car, the user would already be injured or dead. Do you think that driver will be consoled by issuing him a new safer car (A debug car)? One that goes slower, but still faster than he needs? We as developers need to start thinking about the actual impact of bugs on our customers. Not just bug counts, or bug frequency, but the impacts of such bugs. Data loss can be catastrophic, and often is.

It’s not just about limiting injury. In many accidents the occupants injuries are lessened, and often averted. But think about things like ABS (anti lock braking systems). Not only can ABS lessen injury, in many cases it prevents an accident all together! The same principles exist in software, but if we do not put them in our software our users cannot benefit from them.

Enter .NET

Somehow I had to mention .NET. And of course I am. One of the reasons I originally took this job is I love .NET. .NET embodies many of the best practices I have long believed in, and it is forcing developers to start practicing and using methodology that computer scientists have long since adopted as good. Too many developers are habitual, and it often takes something like .NET to force them to change. What do I mean? There are many examples, but one primary one is .NET’s memory checking. In .NET it is impossible to have a buffer overrun. It just cannot happen. Why? Because there are no pointers for one, but also because the CLR checks for such items internally, and there is no way for a developer to turn it off. .NET implements and forces this and many other best practices on developers.

Can .NET applications crash? Sure they can. Developers will always create their own bugs. But the difference is in severity of the outcome. Just as in a car, if you have a crash of the same scenario of a car with safety devices and one without, the one with safety devices is much better at protecting is occupants. Don’t believe me? Again do some data analysis of traffic accidents. While in a few rare cases not wearing a seat belt may have saved a life, seat belts save magnitudes more lives than they take. In fact, of all the safety devices in a car, putting on your seat belt alone is the single largest safety step you can take. By itself it out does every other safety device in cars today. Now imagine if we equip our software with seat belts. But just as it was very difficult (and still is in many parts of the world) to get people to actually use their seat belts, we have the same issues with developers. Education, conviction, and habits.


What do you think? Which do users want? More stable software? Or faster? Of course both – but at least which one has priority? Use the post a comment link below (on the web version, open in web browser if you do not see it) to provide your feedback.


Comments (16)
  1. Dimitri Mihailov says:

    Brilliant and thoughtful. Bravo!

  2. Olaf Monien says:

    Actually I’ve read about software being compared with cars a few times in the past, but not in that extensive, but entertaining way.

    Imo users want always both fast *and* secure cars. Often they don’t care about security – until they hit a tree in the worst case.

    The designers of cars/software have a big liability to provide stable/secure products. Quick hacked products, without reasonable time spent on the chosen tools and frameworks should never be sold/bought.

    There have been seat belts before .NET was invented, but .NET makes it much more easy to actually use them.

    Would you drive a wreck car, "constructed" by somebody you don’t know, built in a muddy backyard, where the "engineers" maybe even don’t know what a seat belt is?

  3. Jim Hubbard says:

    I support several small businesses and all that that entails. PC hardware, monitors, printers, wireless networks and, of course, a plethora of software applications.

    The software applications range from home-grown to enterprise applications like Quickbooks Enterprise and Microsoft Server 2003.

    I have been on thousands of calls for help, and speed has always been a secondary factor to my clients.

    In cars, when things go wrong, speed kills people. In software, when things go wrong, speed kills productivity.

    Think about it like this…. If your app is stable and adequate, you get work done. Every day, your app keeps up with you and you are as productive as you can be. Your productivity is at 100%. (Kind of like when you drive at a reasonable speed – whatever speed you can without crashing – you are covering distance at optimum speeds.)

    But, when an app crashes (like when a car blows a tire), everything stops until the app (and, God forbid) the data can be restored to working conditions. But, that’s not all….

    You also get this fabulous Ginsu knife! Just kidding…

    What you DO get is a frustrated employee. An employee that has to "get back in the groove" again. (Like when somebody interrupst your programming to ask you a vital question about what you are wearing to the office party Friday night.)

    Now this employee has to figure out what data was entered, what data was corrupted, what data was lost, and where to start again. And, even IF they trust the software enough to start again.

    The frustration takes a mental toll on the employee’s productivity. Many times they will unintentionally slow down, thinking that perhaps they made a mistake, or looking for where the program went wrong and afraid that any keystroke could blow another tire …… sending them into another data spin-out.

    Besides, employees can only type so fast anyway. Who are you racing? You already beat the user.

    But, employees that are comfortable with thier software (i.e. not fearing the next crash) are more confident and actually work faster. They can concentrate on the task and not the tool. They are happy….and that equals greater productivity.

    For all of the clients I have (attorneys, realestate agents, doctors, business owners, etc.), they’d rather have dependable software than speedy software – at least for everyday business applications.

    Great article…..keep it up!

    BTW….I was oe of .Net’s buggest detractors when it firat anihlated my beloved VB….but, now, I absolutely love it. Especially the changes in VS 2005!

    (OT…I tried to contact you through the email option on your Kudzu site, but it didn’t work. I have an Indy question that I haven’t been able to find an answer to on the site or in the NGs that I’d like to ask you, but I am not sure this is the forum for it. I’d appreicate it if you could answer a tiny question or 2 for me.)

  4. Sweta says:

    Just loved the comparision.

    Agree with you we need secure systems than faster one.



  5. John says:

    Blunt truth is that .Net applications crash just as much as native applications, and maybe more as programmers are new to the framework and make a variety of mistakes.

    To improve stability, developpers should stop trying to believe that "this time, we’re doing it right", ’cause they aren’t. They should just stop inventing new technology and new bugs, and instead *fix* what they have, rather than create new code, find that it becomes just as big a pile of pooh as the old one after some time, and then create some other code.

    Stop the neverending race, *freeze* features for *years* and fix them. If you keep adding features, new language stuff, new frameworks and new classes, you’re just creating new bugs.

  6. prix1k says:

    Cars are useful in our days, but without <a href=http://www.about-software.info/>software</a&gt; we can’t live too.

  7. banhinc says:

    Software by its nature is open and flexible.  That’s what makes it so powerful.  Car is a fixed hardware defined and controlled one the particular manufacture.  Where as Windows OS has to work with many different hardware manufacture and support many different software publishers.  It’s not a good direct comparison.

    Computer crash because software are badly written causing memory leaks and memory overrun.  Before .NET, managed code, it’s up to the programmers to allocate and manage memory usage properly.  When memory aren’t released after usage, you will get memory leaks.  When you don’t use allocated memory properly, you will overwrite other memory buffer or instruction code causing crashes.  With managed code, the situation has gotten better.

  8. Memmorium says:

         Good idea!

    P.S. A U realy girl?

Comments are closed.

Skip to main content