New programmers are often given tasks such as writing a program to read a list of numbers and calculate their average. So the programmer creates a list of ten numbers which he uses to test his program. After a while, he has a program that works perfectly. He even tries a list of five numbers and a list of twenty numbers and it continues to work perfectly.
However as soon as he releases the program into the public domain, he receives reports that it isn't working. Confused, he investigates the reports and finds out that people have lists that contain letters as well as numbers. Or they are using commas instead of spaces to separate the numbers. Or the list is empty and the program crashes with a divide-by-zero error. Or the list can't be found. The naïve programmer's first response is to tell the users that they're doing it wrong. The program expects a list of numbers so give it a list of numbers! Sheesh.
The more experienced programmer realizes that programs shouldn't crash and burn just because they can't handle the input correctly. They should give advice to the user to help them provide appropriate input and be nice about it.
Similarly with parenting young children. It is sometimes possible to create a perfectly quiet environment when you have only one child. Though it can still require a lot of effort by the parents to keep it that way. But what happens when you have visitors, or have more kids, or have noisy cars in the street? At some point it becomes easier for everyone if the baby can sleep despite the background noise or the ambient light and feed happily despite the odd location or the precise milk temperature.
Although having siblings banging loudly on the baby's door might still be input that it is better to try to prevent!
If only the baby would "give advice to the parent to help them provide appropriate input, and be nice about it" ;-)
ReplyDeleteIf I understand your point:
ReplyDeleteProperly formatting the input numbers is a transaction cost of running the software. But this transaction cost can be minimized per transaction by a larger implementation cost that makes the cost internalised.
Since the software is written once but run often, the good programmer pays the implementation cost of making more tolerant software, in order to lower the effort (transaction cost) of using their software.
Similarly, since habits are ingrained once but utilized often, the good parent absorbs the (implementation) cost of training their child in tolerance for noise, and reaps the benefit of an easy-sleeping child.
Except that some things don't occur often enough (and thus venn-intersect with the group of unexpected things) to be worth implementing the habit.
Likewise the programmer/parent has limited resources with which to implement habits, and may be required to make some choices about which matter.
But also, internalising all the transactions costs will 'bloat' software (it may take longer to do all the reformatting, checks, etc as to do the actual work, while a similar program that is less careful will be faster - which is a lower transaction cost of a different type for users who's data is already good).
So then, can a child be 'bloated' with too many habits? A child trained to be cautious of strange cars, roads, machinery and equipment, moving water, sharp things, lazers, wild animals, and other things (all good to be cautious of) may lose out in some circumstances to a more impulsive child who takes risks (just gets on a plane and goes overseas instead of saving up enough money first).
In any case, that sibling at the door does sound like a helpful QA tester.
Nice! I think you understand it a little too well...
DeleteMaybe to satisfactorily solve the bloating problem, the child needs to learn the habit of evaluating habits. That is, the child becomes self-programming...
I had another thought. Consistency among users/populace lowers the implementation cost for all software devs/parents. i.e. knowing that adults won't smoke around children removes the need to train children to avoid smoke. Or knowing that users will recognise the Disk symbol as Save enables the programmer to simply implement the standard icon.
ReplyDelete