Greenfield Development

Start with nothing and create a finished product with no existing code, design, or previous system.

• Most SE books, education, processes, tools, etc. stress greenfield development
• However, there is little pure greenfield development in the real world
• What Computer Science majors see themselves as doing

Brownfield Development

Start with an existing project/environment and create a finished product with existing code, design, or previous system

• Most SE books, education, processes, tools, etc., treat brownfield development as a side topic
• However, most development in the real world is brownfield development
• What Computer Science majors often end up doing

Maintenance

Changes to an existing system

• Overwhelming part of the cost of the system over its lifetime (80%). However, typically not built into the cost structure
• Bad terminology. Maintenance of software is not the same as maintenance in other fields
• Most SE books, education, processes, tools, etc., treat maintenance as a side topic. However, much of what software developers do are maintenance activities.

IT Spending (1999) [Bohner,S]

Relative Costs of Phases of a Life-cycle [Schach 1999]

Categories of Maintenance [Swanson, ISO/IEC 14764]

• Corrective
  • Fix bugs/problems
• Adaptive
  • Change to fit new environment (API, compiler)
• Perfective
  • Improve performance or maintainability
• Preventive
  • Detect and correct latent problems before they become actual problems

Software Evolution

Software Evolution = Software Development + Software Maintenance

• Focus on supporting maintenance, not development for processes, tools, etc.
• Does not distinguish between development and maintenance
• Example: open-source model

Lehman's Laws of Software Evolution

• Originally based on observations of a few commercially-developed systems
• 3 to 8 "laws", but are observations.
• Limited data, however, is an important start.
• Individual laws are not important, only the overall conclusions.
• Interesting tie-in to disruptive innovation and why companies have difficulty changing.

Law I: Continuing Change

A program that is used must be continually adapted; else, it becomes progressively less satisfactory

• Software has to be frequently updated.
• Why? Development, installation, and operation of software change the environment.
• Why? Assumptions are made during development but are invalidated by changes in the environment.
• If software evolution is not allowed to occur, satisfaction with the software declines.

Law II: Increasing Complexity

As a program is evolved, its complexity increases unless work is done to maintain or reduce it

• Similar to the Second Law of Thermodynamics (entropy)
• Changing environment leads to more complexity
• Why? Unstructured interactions between parts of the software -> increase in entropy
• Why? Growth in complexity -> more time to add a new feature. Reducing complexity -> less time for new features
• Need a balance of adding new features and reducing complexity

Law III: Self Regulation

The program evolution process is self-regulating with close to normal distribution of measures of product and process attributes

• Over time, all iterations will have the same characteristics (bugs, complexity, efficiency, etc.).
• Over time, all projects will have the same characteristics.
• Why? The development team is part of a larger organization whose interests and goals include more than this project.
• Why? Feedback (resource allocation, pay) from all levels of the larger organization work to keep the project in line.
• If the organization's products have good characteristics, this is good; if not, this is bad.

Law IV: Conservation of Organisational Stability

The average effective global activity rate on an evolving system is invariant over the product life time

• Rate of development (features, tasks, etc.) doesn't change much over the long-term life of the product.
• Counter-intuitive. People (especially managers) believe managers make decisions that affect the activity.
• Why? Managers do control resources and may control what we do. However, union rules, the skillset of personnel, etc., constrain management. System characteristics, e.g., complexity, also constrain them.
• Providing additional resources may reduce overall effectiveness [Brooks].

Law V: Conservation of Familiarity

During the active life of an evolving program, the content of successive releases is statistically invariant

• Good progress is made when everyone is familiar with the goals
• The more changes/additions to the software, the more difficult it is for everybody to be familiar with all the goals
• Larger the change, the less likely everybody is familiar with it
• Trigger points at which this occurs

Law VI: Continuing Growth

Functional content of a program must be continually increased to maintain user satisfaction over its lifetime

• Appears the same as Law I: Continuing Change, but isn't
• Scenario: Customer states the requirements, but due to resources (budget, time, etc.), we don't implement all the requirements.
• Eventually, unimplemented requirements may be requested by users.

Law VII: Declining Quality

… programs will be perceived as of declining quality unless rigorously maintained and adapted to a changing operational environment

• Software performing satisfactorily for a long time may suddenly exhibit unexpected behavior.
• Why? The gap between software and the real-world operational domain. The real world is constantly changing.
• Why? This uncertainty about software increases with time unless we take action during maintenance.
• User satisfaction changes over time.

Law VIII: Feedback System

Programming Processes constitute Multi-loop, Multi-level Feedback systems and must be treated as such to be successfully modified or improved

• All other parts of this set of laws include feedback.
• Multi-loop: various iterations
• Multi-level: users, development team, testing, management, critics

Lehman's Laws Summary

Law I: Continuing Change
Law II: Increasing Complexity
Law III: Self Regulation
Law IV: Conservation of Organisational Stability
Law V: Conservation of Familiarity
Law VI: Continuing Growth
Law VII: Declining Quality
Law VIII: Feedback System

• Software must change over time.
• Changes cause complexity. Complexity increases the cost of change—resources allocated to reduce complexity take away from features.
• Software projects in an organization tend towards the same quality, bug rate, etc.
• Over time, the rate of development for each iteration doesn't vary much. Tend to meet the same number of goals with each iteration.
• Must implement features that were previously not considered necessary.
• Without changes, the software appears to decrease in quality.
• What affects software evolution is a multi-level, multi-iteration process.