Semester 1: Costly 'Simple Code' vs Smart Semi-Interpretive Code
This fairy tale is about two schools at a university. The School of Fine Arts and the School of Engineering. The admissions policy changed almost every semester, and each school had to adapt. Each school had its own computer systems and programmers. (One might ask why, but fairy tales are like that.) In the School of Fine Arts, the very expressive programmers had simple, easy-to-understand programs. Every program was written out in simple source code that followed the pseudo-code from the analysts. The programmers tried to keep each program in one file.
In the School of Engineering, the programs often seemed obscure and definitely different that those in the School of Fine Arts. The programs were very repetitious; almost every one followed the design of an existing, really old program. Usually, the source code only had a header, a local data area, data copylibs, a short, gritty procedure section, and beaucoup procedure copylibs. The header contained the program name, a version counter, and comments. There were no remnants of older versions; there was no history except the version counter. To see the history, a programmer had to run a utility. To see all of the source code for one program, a programmer had to compile with a bunch of switches, and the compile could not be done in the production account. So, a person could see the header info in production, but to verify the exact code, a person had to trust the installation logs or had to run another utility to look at the machine code. There was no way to compare source code in production.
The VP of IT Services liked Fine Arts because the programs seemed so intuitive and easy-to-read, On the other hand, Engineering only had two programmers whereas Fine Arts had three analysts and four developers. Also, Engineering was notorious for reporting errors, particularly in specifications, which annoyed the VP, the analysts, and several self-taught power users.
The new admissions criteria, as announced by the provost, was quite simple. The specs came as text in a friendly letter. "If a freshman applicant had a score in the 90th percentile or better on the SAT and had a rank in the 50th percent or better in his class at high school, then the university would accept the applicant. Likewise, a score of 80 or better and a rank of 63 or better, or a score of 60 or better and a rank of 88 or better."
In the School of Engineering, the programs often seemed obscure and definitely different that those in the School of Fine Arts. The programs were very repetitious; almost every one followed the design of an existing, really old program. Usually, the source code only had a header, a local data area, data copylibs, a short, gritty procedure section, and beaucoup procedure copylibs. The header contained the program name, a version counter, and comments. There were no remnants of older versions; there was no history except the version counter. To see the history, a programmer had to run a utility. To see all of the source code for one program, a programmer had to compile with a bunch of switches, and the compile could not be done in the production account. So, a person could see the header info in production, but to verify the exact code, a person had to trust the installation logs or had to run another utility to look at the machine code. There was no way to compare source code in production.
The VP of IT Services liked Fine Arts because the programs seemed so intuitive and easy-to-read, On the other hand, Engineering only had two programmers whereas Fine Arts had three analysts and four developers. Also, Engineering was notorious for reporting errors, particularly in specifications, which annoyed the VP, the analysts, and several self-taught power users.
The new admissions criteria, as announced by the provost, was quite simple. The specs came as text in a friendly letter. "If a freshman applicant had a score in the 90th percentile or better on the SAT and had a rank in the 50th percent or better in his class at high school, then the university would accept the applicant. Likewise, a score of 80 or better and a rank of 63 or better, or a score of 60 or better and a rank of 88 or better."
Fine Arts has Simple Code
After a day of meetings, one of the analysts took a day to set-up the flow chart using structured methods. By the next day, a developer had pseudo code, which flowed from the chart and converted quickly to actual 4GL. A day of peer review by three people and a day of testing passed. The sysadmins took two days to install and one day to final test. Eight calendar days and eleven man days of effort for Fine Arts. << Do you see the error ; see Limits >>
This concern about greater than or equal suggested that the entire Fine Arts implementation was slightly wrong. Months later, the Fine Arts people did not feel that the difference was significant. Finally, a daughter of a donor was rejected. Her scores of 90 and 55 did not grant her admission. The donor complained that his daughter had met the published criteria. Fine Arts spent a day correcting the signs, a day testing, and another two days implementing again.
Engineering copied a Similar Program
The first reaction by the junior programmer in Engineering was "why does the chart have only 'greater than' signs?" The analyst explained that her key board only had greater than signs and she thought that inserting the equal signs made the chart look messy. The assistant to the provost insisted that the program actually test for greater than or equal, but for aesthetic reasons, the chart did not change.
After a day of meetings, one of the analysts took a day to set-up the flow chart using structured methods. By the next day, a developer had pseudo code, which flowed from the chart and converted quickly to actual 4GL. A day of peer review by three people and a day of testing passed. The sysadmins took two days to install and one day to final test. Eight calendar days and eleven man days of effort for Fine Arts. << Do you see the error ; see Limits >>
This concern about greater than or equal suggested that the entire Fine Arts implementation was slightly wrong. Months later, the Fine Arts people did not feel that the difference was significant. Finally, a daughter of a donor was rejected. Her scores of 90 and 55 did not grant her admission. The donor complained that his daughter had met the published criteria. Fine Arts spent a day correcting the signs, a day testing, and another two days implementing again.
Engineering copied a Similar Program
The first reaction by the junior programmer in Engineering was "why does the chart have only 'greater than' signs?" The analyst explained that her key board only had greater than signs and she thought that inserting the equal signs made the chart look messy. The assistant to the provost insisted that the program actually test for greater than or equal, but for aesthetic reasons, the chart did not change.
Engineering has Better Code
In the School of Engineering, the junior programmer copied a diagram of a commendation letter and produced in a day the chart at the right: The assistant saw that the chart by Engineering was so very different. 1) She asked "why is there a table lookup?" and when the programmer explained the process, she liked what she saw. "A human looks up the scores and ranks in an understood table, and composes a letter to the applicant." 2) The assistant also wondered how input into the table was done; the programmer showed her the existing standard table-maintenance program. 3) "Why did you put school and semester into the table when the specs from the Provost said nothing about those?" The junior programmer explained that virtually all the tables have school and semester because those control so many actions. 4) She could see the pattern of school, semester, SAT score, high school rank, and action. "Why is there a result? Isn't the 'ACCEPT' or 'REJECT' the result?" The junior programmer explained that all data base lookups return a result. In this situation, if the parameters are bad or if the action is empty, the result is a non-zero value. The program sort of verifies the data. 5) "Why is there an error2?" Because we always check case statements for failure; in this chart, some string other than 'accept' or 'reject'.would be an error . |
Engineering had started two days after Fine Arts. The junior programmer had taken two days, then testing one day, and implementation parts of two days: about five calendar days and about five man days. The next two semesters of changes brought more revelations. During installation by the sysadmins, the analyst read thru the documents from the School of Engineering. After some heated words, the analyst wanted to know where the table came from, and the assistant to the provost explained. << the programmers smiled >>
Fine Arts spent 12 calendar days and 16 man days. Engineering had worked on 5 calendar days and 6 man days.
see Semester2
Fine Arts spent 12 calendar days and 16 man days. Engineering had worked on 5 calendar days and 6 man days.
see Semester2