A 2013 webinar at Cyber Security & Information Systems Information Analysis Center, presented some Immutable Laws of Software Development. These are worth repeating every time there is a suggestion hat some method or another, or some new and untested idea is put forth that will increase productivity by 10X or increase your profitability by NOT doing core business processes.
Here's the list presented in the webinar and is dedicated to Watts Humphrey who said all these in the past. For each Immutable Law, I've made a suggestion on how to avoid the undesirable outcome.
- The number of development hours is directly proportional to the size of the software product
- Size Matters
- Build products in chunks of capability, deploy them incrementally when possible to provide measurable value
- Increase the maturity of this capability with Capabilities Based Planning
- When buyers and suppliers both guess as to how long a project should take, the buyers guess will always win
- Credible cost, schedule, and technical performance estimating must be in place and jointly used by buyer and supplier
- The basis of estimate must include risk adjusted baseline for reducible and irreducible risks
- When management compresses schedule arbitrary the project will end up taking longer
- Any project without margin is late, over budget, and produces poor quality on day one
- Reducible and Irreducible uncertainty must be modeled and handled if this is o be avoided
- Team morale is inversely proportional to the arbitrary and unrealistic nature of the schedule imposed on the team
- All project variables - programmatic and technical must have protective margin
- Schedule problems are normal, management actions to remediate will make them worse.
- Margin is needed for everything since all project variables are random variables
- When poor quality impacts schedule, schedule problems will end up as quality disasters
- Technical performance (quality) require cost and schedule margin to achieve to needed goal
- Those that don't learn from poor quality's adverse impact on schedule, are doomed to repeat it.
- Recording past performance in a statistically correct manner provides reference classes for modeling future performance
- The fewer facts you know about a project during development, the more you will be forced to know later
- Systems Engineering is an anchor discipline for all successful projects.
- This is no more important than on software development projects.
- The Systems Engineering processes applied to software development are a critical success factor
- The number of defects injected during development will be directly proportional to the development hours expended
- The number of defects found in production use will be inversely proportional to the percent of defect removed prior to integration, system, and acceptance testing.
- Formal defect modeling is the starting point for quality improvements
- Test coverage metrics are a starting point
- The number of defects found in production use will be directly proportional to the number of defects found in integration, systems, and acceptance testing.
- Same as above
- When testing is the principal defect removal method during development, corrective maintenance will account for the majority of the maintenance spend.
- Designed quality is the basis of reducing defects
- Designed quality starts with architecture, interface management, process and data models
- The amount of technical debt in inversely proportional to the length of the agile sprint
- 2-week sprints produce more debt that 4-week sprints
- Scrum and agile in general have no notion of margin so without margin debt increases
- The earliest predictor of a software project's cost, schedule, and the quality outcome is the quality of the development process through code complete.
- Process is King
- Management actions based on metric not normalized by size will make the situation worse.
- All numbers must be properly modeled, statistically sound, and used to make management decisions.
- On a 40 hour week, the number of task hours for each engineer will actually work is under 20, unless steps are taken to improve it.
- Work processes must be modeled, recorded, and assessed to determine the capacity for work by the team.
- Successful cost, schedule, and quality outcomes depend on the degree of convergence between the organization's official process, the teams' perceived process, and the individual's actual processes.
- Process is King
- Insanity is doing the same thing over and over and firing the project manager and or contractor when you don't get the results you expected.
- Strategy for the organization requires tangible assessments of the Critical Success Factors and should never be confused with Operational Effectiveness.
- If we ask someone to do something like making a change - what are the measures of Effectiveness and Performance for the change that can be assessed to find the root cause of the failure and the needed corrective actions.
- Don't have those? It's gonna fail.
