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

Maintenance Costs Often Exceed Development Costs

Keep the Ship Afloat
Organizational survival should be the the top priority.  Once when NEC was going thru a big down turn, I laid myself off because the few other IT workers were actually doing more important, day-to-day work than I was.  About once a week for three months I came for meetings and for strategy sessions.  NEC recovered and continued another dozen years.  Hopefully such extreme conditions are rare.  Dealing with such conditions does not make for good policy in the long run.  The assumption is that the organization is surviving and making economic progress.



Stability is King
Until the system is stable, urgency reigns.  Some wise man might have enough moxie and enough workers to balance the demands of an unstable system against the demands of other projects.  Finding and fixing bugs is a first step.  As the fixing process matures, each fix of the same bug should becomes faster and better until reaching some plateau.  The causes of instability span the spectrum of IT services.  At APU, a rat ate into a cable under a building.  At first, the interruption was intermittent; finally the rodent severed the cable. 

Governmental changes, uninformed administrators making policy changes, and overly zealous implementors trigger substantial upheavals.

Payroll Costs
The organization paid several million dollars for its PeopleSoft system.  Some people were quite disgusted.  The old system almost seemed free.  At least with the new system, a large number of colorful new screens and menus appeared, and web browsers could navigate thru the system.   Much activity swirled around the new jobs titles and the many people who filled them.  Departments across the organization now had data specialists to maintain the data and its code tables.  Some departments had embedded IT people who served as liaisons with the main IT department.  The managers of several departments wondered why the clerks kept falling days behind: the new screens were slower and the new screens had not been optimized to follow the organizations patterns of data entry.  Payroll tripled.


Chaos and the Tower of Babel
Another organization decided that writing software was far too expensive.  Instead their managers read Gartner and other leading reviewers of IT software; then they bought the very best for each of the organizations thirty functions.  The calendar program was so powerful that it produced output in twelve languages and only needed one programmer half-time.  The HR system was also multi-language, which helped with Spanish speaking employees.  Only one programmer was needed to keep the HR interfaces into the other modules running.  Some of the packages came with related computer languages; this made some customizations easier.  In total, the organization needed about twenty programmers for the thirty modules and no  fewer than a dozen language tools.  What were the costs?

Big Projects with little Steps

Tactical Attacks

Friday Afternoons
When we had achieved our crew's scheduled goals by Thursday noon, the five programmers could choose a fun task for Friday afternoon.

Pattern Matching

Shared Algorithms and Share Libraries





PCC 1982 - 2014