Simple Solutions to Complex Problems
  • Simple Solutions
    • Documents Live Once
    • Good JIgs
    • Polya and Friends
  • Long Term Relations
    • Customers & Projects >
      • APU OverView >
        • APU Early Years
        • APU Middle Years
        • APU Late Years
      • AQMD >
        • DataGeneral v Hewlett Packard
      • Big Lots
      • The Federate Group >
        • Stabilizing the System
        • The Cash Register System
        • Later Projects
      • Munson Management Systems
      • National Electronics
      • Richey Electronics
      • Sierra Pacific Investments
      • Other Customers
  • Diagonal Method
    • D2-M2 >
      • Diagonal differs from Agile
      • Maintenance Projects
      • Manufacturing Projects
      • Research Projects
    • Data Structures >
      • Data Levels
      • Data Logging
      • Data Merging
      • Data Input Buffers
      • Data Sorting
      • Data Deltas
    • Readable Source Code >
      • Readable Code Modifications
      • Readable Paradigms
      • Readable Style
    • Critical Path Method >
      • CPM Data Tasks
      • CPM Menu and Security
      • CPM External Tasks
      • CPM: Early Calculations
      • CMP Stem to Stern >
        • Work Units
    • Semi-Interpretive Mindset >
      • Simple Semi-Interpretive Case Study 1
      • Semi-Interpretive Case Study 1 -- Semesters 2 and 3
      • More Thorough and Efficient
      • Software Research Northwest
    • Semi-Interpretive Methods
    • Concepts and Practices >
      • Data Changes
      • Data Stacks
      • Data Tokens and Loose Linking
    • Diagrams & Examples >
      • Venn Diagrams
      • Music Score as a Diagram
      • Cause & Effect Diagrams
    • Dictionary and Lexicon
  • Programmers
    • Tools and Languages >
      • python considerations
      • program names, like sa5comm
    • Perspectives of a Manager
    • ToDo
    • HTML testing
    • Private Thoughts
    • Leads
  • Contact Pilgrim
    • Land of the Free
    • Pilgrim Legal Status
    • Index to Pages
  • New Page
  • Stonehenge Simply Done

Semi-Interpretive becomes more thorough and efficient; then it takes over.

For the fourth following semester, Spr14, the provost wanted schools to have the ability to process two semesters concurrently.  The provost realized that during the fall, some students were applying for spring and some for the next fall.  The provost also wanted statistics.  Engineering had a much higher ratio of rejections than Fine Arts had. 

The Error
The assistant to the provost detected the cause of the higher ratio.  In the table for Engineering, the row with score = 0 catches all of the applications with scores less than 50.  In the chart for Fine Arts, any score less than 50 falls thru to the exit; no action is taken. This error existed for three semesters and several reviews.  The Provost was suspicious of the School of Engineering, but his own assistant found the error.  The error explained several letters from applicants who complained about a lack of acceptance decisions.

As for the concurrent requirement, the program in Engineering handled multiple semesters concurrently from the beginning, as was demonstrated in the second semester.  The program did require the input of the semester key.  The program in Fine Arts would have required significant doubling of its logic, and then the developers realized that for each semester, the program required much more maintenance and testing to install two semesters.  Consecutive semesters usually had different flowcharts. On the menu system, the system admins in Fine Arts had been keeping a version of the program for each semester; hopefully, the clerk chose the correct menu choice.

Fine Arts again took 11 days including one to find the big bug for a total of 41.  Engineering spent 2 hours adding table entries and a day of testing for a total of 12 days.  Engineering did not need to install.

By the next semester, the Provost tweaked the specs a bit. The programmers in Fine Arts estimated another 6 to 11 days to modify, test, and install. Engineering estimated one day for table entries and testing.  The programmers in Fine Arts recommended adopting the program from Engineering.

FIne Arts about 41 days, Engineering about 12 days.
This ratio for maintenance days is typical when comparing typical methods to semi-interpretive methods.  Finding real life comparison proves difficult.  Most CIOs seem to shy away from scrutiny, especially when inspection might reveal great in-efficiencies.  During the 1980's, Price Waterhouse reviewed the Federated Group and compared it to Circuit City and to Silo.  The accountants at Price Waterhouse said that the Group had more functionality and better controls than the other two.  The Group had five programmers and Circuit City supposedly had over two hundred.  Such a ratio is so extreme that it begs for confirmation.    See Software Research Northwest

PCC 1982 - 2014