$6.2 IMPLEMENTATION VARIATIONS 125 The danger of overspecification Why is it so bad to use a particular representation as specification? “ABOUT SOFT. The results of the Lientz and Swanson maintenance study,which you may recall, WARE MAINTE- give a hint.More than 17%of software costs was found to come from the need to take into NANCE”,I.3.page account changes of data formats.As was noted in the discussion,too many programs are 17. closely tied to the physical structure of the data they manipulate.A method relying on the physical representation of data structures to guide analysis and design would not be likely to yield flexible software. So if we are to use objects or object types as the basis of our system architectures, we should find a better description criterion than the physical representation. How long is a middle initial? Lest stacks make us forget that,beyond the examples favored by computer scientists,data structures are ultimately connected with real-life objects,here is an amusing example, taken from a posting on the Risks forum(comp.risks Usenet newsgroup)of the dangers of a view of data that is too closely dependent on concrete properties: Risks forum,10.74, My dear mother blessed (or perhaps cursed)all of her children with two middle initials, 3Jan.1993.Post- in my case“D”and“E".This has cau.sed me a good deal of trouble. ing by Darrell D.E. Long:Dehuman- It seems that TRW sells certain parts of your credit information,such as your name and ization by old a demographic profile.I recently got a new credit card from Gottchalks and found to my Cobol programs". chagrin that my name had been truncated to "Darrell D.Long".I went to the credit Abbreviated. manager and was assured that things would be fixed.Well,two things happened:I got a new credit card,this time as"Darrell E.Long",and TRW now has an annotation in my See exercise E6.5. file to the effect"File variation:middle initial is E".Soon after this I start getting mail page 161. for "Darrell E.Long"(along with the usual "Darrell Long"and "Darrell D.Long"and the occasional "Darrell D.E.Long"). I called up the credit bureau and it seems that the programmer who coded up the TRW database decided that all good Americans are entitled to only one middle initial.As the woman on the phone patiently told me "They only allocated enough megabytes (sic)in the system for one middle initial,and it would probably be awfully hard to change". Aside from the typical example of technobabble justification ("megabytes"),the lesson here is the need to avoid tying software to the exact physical properties of data. TRW's system seems similar to those programs,mentioned in an earlier discussion,which "knew"that postal codes consist of exactly five digits. See page 18. The author of the message reproduced above was mainly concerned about junk mail, an unpleasant but not life-threatening event;the archives of the Risks forum are full of computer-originated name confusions with more serious consequences.The "millenium problem",mentioned in the discussion of software maintenance,is another example ofthe dangers of accessing data based on physical representation,this one with hundreds of millions of dollars'worth of consequences.§6.2 IMPLEMENTATION VARIATIONS 125 The danger of overspecification Why is it so bad to use a particular representation as specification? The results of the Lientz and Swanson maintenance study, which you may recall, give a hint. More than 17% of software costs was found to come from the need to take into account changes of data formats. As was noted in the discussion, too many programs are closely tied to the physical structure of the data they manipulate. A method relying on the physical representation of data structures to guide analysis and design would not be likely to yield flexible software. So if we are to use objects or object types as the basis of our system architectures, we should find a better description criterion than the physical representation. How long is a middle initial? Lest stacks make us forget that, beyond the examples favored by computer scientists, data structures are ultimately connected with real-life objects, here is an amusing example, taken from a posting on the Risks forum (comp.risks Usenet newsgroup) of the dangers of a view of data that is too closely dependent on concrete properties: My dear mother blessed (or perhaps cursed) all of her children with two middle initials, in my case “D” and “E”. This has caused me a good deal of trouble. It seems that TRW sells certain parts of your credit information, such as your name and a demographic profile. I recently got a new credit card from Gottchalks and found to my chagrin that my name had been truncated to “Darrell D. Long”. I went to the credit manager and was assured that things would be fixed. Well, two things happened: I got a new credit card, this time as “Darrell E. Long”, and TRW now has an annotation in my file to the effect “File variation: middle initial is E”. Soon after this I start getting mail for “Darrell E. Long” (along with the usual “Darrell Long” and “Darrell D. Long” and the occasional “Darrell D. E. Long”). I called up the credit bureau and it seems that the programmer who coded up the TRW database decided that all good Americans are entitled to only one middle initial. As the woman on the phone patiently told me “They only allocated enough megabytes (sic) in the system for one middle initial, and it would probably be awfully hard to change”. Aside from the typical example of technobabble justification (“megabytes”), the lesson here is the need to avoid tying software to the exact physical properties of data. TRW’s system seems similar to those programs, mentioned in an earlier discussion, which “knew” that postal codes consist of exactly five digits. The author of the message reproduced above was mainly concerned about junk mail, an unpleasant but not life-threatening event; the archives of the Risks forum are full of computer-originated name confusions with more serious consequences. The “millenium problem”, mentioned in the discussion of software maintenance, is another example of the dangers of accessing data based on physical representation, this one with hundreds of millions of dollars’ worth of consequences. “ABOUT SOFT￾WARE MAINTE￾NANCE”, 1.3, page 17. Risks forum, 10.74, 3 Jan. 1993. Post￾ing by Darrell D.E. Long: ``Dehuman￾ization by old Cobol programs''. Abbreviated. See exercise E6.5, page 161. See page 18