When I am asked why a certain program is broken, or why building one takes so long, I respond in terms of "moving parts".
The average automobile has about 150 moving parts.
The space shuttle has 100,000 moving parts.
A complex computer program (Windows, Linux, OSX, Photoshop, Quark Xpress, SAP, Great Plains, etc.) have 1 million or more moving parts.
(I generally consider a subroutine a "moving part").
I then equate installing a new program to adding a new stereo to a car or installing a hitch with a hitch brake. Or I compare different types of factory cars: The low-end models with a manual transmission, no A/C, and manual steering/locks/windows/seats vs. higher-end models with all the options. The more options you add to your car (programs), the more things there are that can break and need to be fixed.
Along the same lines, writing computer applications is like building a space shuttle with lots and lots of moving parts. The more "things" you want a program to do (the more "options" you want on your car), the more "moving parts" you have to build that can eventually break down.
When explaining how programs interact with each other or with the operating system, I use the analogy of aftermarket car parts like stereos: When you install a new stereo in your car, how long it lasts depends on the quality of the car (operating system), the quality of the stereo (the program being installed), the quality of the technician installing the stereo (the programmer), and last but not least, the actions of the driver (end user).
I have found that explaining complex issues in terms of physical everyday activities and objects really helps most people understand just how complex computers are.
Most people are not experienced in virtualization and abstraction, and have a difficult time imagining something that they do not have a physical reference on which to base their visualization processes.
Slashdot Mirror
When I am asked why a certain program is broken, or why building one takes so long, I respond in terms of "moving parts".
The average automobile has about 150 moving parts.
The space shuttle has 100,000 moving parts.
A complex computer program (Windows, Linux, OSX, Photoshop, Quark Xpress, SAP, Great Plains, etc.) have 1 million or more moving parts.
(I generally consider a subroutine a "moving part").
I then equate installing a new program to adding a new stereo to a car or installing a hitch with a hitch brake. Or I compare different types of factory cars: The low-end models with a manual transmission, no A/C, and manual steering/locks/windows/seats vs. higher-end models with all the options. The more options you add to your car (programs), the more things there are that can break and need to be fixed.
Along the same lines, writing computer applications is like building a space shuttle with lots and lots of moving parts. The more "things" you want a program to do (the more "options" you want on your car), the more "moving parts" you have to build that can eventually break down.
When explaining how programs interact with each other or with the operating system, I use the analogy of aftermarket car parts like stereos: When you install a new stereo in your car, how long it lasts depends on the quality of the car (operating system), the quality of the stereo (the program being installed), the quality of the technician installing the stereo (the programmer), and last but not least, the actions of the driver (end user).
I have found that explaining complex issues in terms of physical everyday activities and objects really helps most people understand just how complex computers are.
Most people are not experienced in virtualization and abstraction, and have a difficult time imagining something that they do not have a physical reference on which to base their visualization processes.