The Immutable Laws of Software Development

Back in 2014, CrossTalk magazine had an article titled “If it passes test, it must be OK” – Common Misconceptions and The Immutable Laws of Software by Girish Seshagiri.  In it, Girish provides the list below and talks about all of these in detail.  However, it was the 10th law listed, which I highlighted with bold and italic text below, that struck me as the most relevant to Business Analysts.  What do you think of the “Immutable Laws” below?

The Immutable Laws of Software Development

  1. The number of development hours will be directly proportional to the size of the software product
  2. When acquirers and vendors both guess as to how long a project should take, the acquirers’ guess will always win
  3. When management compresses schedule arbitrarily, the project will end up taking longer
  4. When poor quality impacts schedule, schedule problems will end up as quality disasters
  5. Those that don’t learn from poor quality’s adverse impact on schedule, are doomed to repeat it
  6. Team morale is inversely proportional to the degree of arbitrariness of the schedule imposed on the team
  7. Schedule problems are normal; management actions to remediate will make them worse
  8. Management actions based on metrics not normalized by size will make the situation worse
  9. Estimating bias will be constant unless steps are taken to eliminate it
  1. The less you know about a project during development, the more you will be forced to know later
  1. In a 40 hour work week, the number of task hours for each engineer will stay under 20, unless steps are taken to improve it
  2. The earliest predictor of a software product’s quality is the quality of the development process through code complete
  3. When test is the principal defect removal method during development, corrective maintenance will account for the majority of the maintenance spend
  4. The number of defects found in production use will be inversely proportional to the percent of defects removed prior to integration, system, and acceptance testing
  5. The number of defects found in production use will be directly proportional to the number of defects removed during integration, system, and acceptance testing
  6. The amount of technical debt is inversely proportional to the length of the agile sprint
  7. Success of software process improvement depends on the degree of convergence between the organization’s official, perceived and actual processes
  8. The return on investment in software process improvement is inversely proportional to the number of artifacts produced by the software engineering process group
  9. Insanity is doing the same thing over and over and firing

Leave a Reply

Your email address will not be published. Required fields are marked *