A person wants to buy a car, so they go to a dealer that provides a way to order a car to specifications.
The person makes selections from a number of options
- Car model
- Car color
- Specific Tires
- Interior options
- Sound system options
- and many others
And gets a car delivered to the specifications. The person looks at the car and is pleased that it looks like everything is to specifications.
The person gets in the car and says
- The steering wheel is too low. Instructions are given to adjust the steering wheel.
- The seat is too close. Instructions are given to move the seat up and back.
- The sound is too loud. Instructions are given to adjust the sound system.
And then the person says
- The roof is too low. Please raise it up a couple of inches.
- It is at this point that things fall apart.
- Perhaps instructions are given to lower the seat to no avail.
- Perhaps explanations are offered as to why roofs are not flexible.
The issue of course, is that certain assumptions are made about cars that are general knowledge.
- We know we can add a steering wheel cover with little impact.
- We know we can usually add a CD player with little impact.
- We also know that if we want to ignition moved to the other side of the steering wheel because we are left handed, that is probably a major alteration.
- We know that the roof of the car cannot be raised or lowered.
The same is not true for software.
When someone comes to a software developer, there is not a clear understanding of what features are easily modified or added, and which ones are not.
- Those of us who have developed software know very well the experience of asking many questions about what the system requirements are, developing a sytem to those requirements, and then being asked why the system does not do a certain functionality that was never discussed.
- If we are lucky, the functionality is as easy as adjusting the seats.
- If we are not lucky, we have to argue why it is so hard to raise the roof a couple of inches.