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

Modifications to Source Code

Mark the header area of the source code systematically
Find a unique group of characters to represent the organization in remarks, which also helps to locate remarks.
  • APU at Azusa Pacific University proved surprisingly unique
  • FGRP at the Federated Group
  • NCC at National Capacitor Corp, which became NEC
  • CII at Capital Investment Incorporated

Mark out entire lines; never bother with replacing a few characters unless correcting a misspelling made today.

Replace contiguous lines

Replace entire routines when only a few old lines remain

Massive Changes
Normal maintenance changes a small percentage of the total program.  For annual maintenance, keeping two years is plenty.  In other words, keep the remarks and cross outs from last year.  Make new cross outs for this year, and insert the new code

Somewhere between 10 and 30 percent, as changes increase, the best policy is to re-write the entire program.  The old program should have remarks pointing to the new program, which should reference the old program. Obviously, the old program should go to the archive. 

Several times during the last forty years, a company has adopted a new nomenclature.  Semesters became terms; sales tickets became sales orders; xxx.  Other times, the manager decided that all variables should have a prefix.  The variable name_last became stu_last_name; account became stu_account.  In another situation, the shop adopted objects for some common ideas.  The result was a change in variable names; dept_name became dept.name because of the dot notation.  Such changes can have mammoth effects on source code.  My suggestion has been to spread the changes across the normal calendar of expected changes and not to rush to make changes.  When programmers have lulls, the changes might fill the schedule. 
xxxxx


PCC 1982 - 2014