Lehman's Laws of Software Evolution

An introduction to software evolution principles for postgraduate electrical engineering students.

"Software that is used must be continually adapted else it becomes progressively less satisfactory."

Relevance to Electrical Engineering

As electrical systems become increasingly software-dependent (IoT, embedded systems, smart grids), understanding software evolution is critical for long-term system maintainability and reliability.

What is Software Evolution?

Software evolution refers to the continuous change and adaptation of software systems after their initial development to meet new requirements, fix issues, and adapt to changing environments.

Historical Context

In the 1970s, Manny Lehman and Laszlo Belady studied the growth and change patterns of IBM OS/360. Their research led to the formulation of laws describing how software evolves over time.

Electrical Engineering Example

Consider an embedded control system for an electric vehicle. Over time, it requires updates for new battery technologies, safety regulations, communication protocols, and user interface improvements. This continuous adaptation is software evolution.

Manny Lehman (1925-2010)

Meir "Manny" Lehman was a computer scientist who made significant contributions to software engineering, particularly in understanding software evolution and the software process.

Background and Contributions

Professor at Imperial College London
Pioneered research on software evolution in the 1970s-80s
Proposed the classification of software into three types: S-type, P-type, and E-type
Formulated the Laws of Software Evolution based on empirical studies

"E-type software evolves. It is embedded in, and responds to, the real world which itself evolves."

Lehman's Software Classification

Lehman categorized software systems into three types based on their relationship with the real world:

S

Specification-based (S-type)

Formally defined problems with deterministic solutions (e.g., compilers, mathematical software)

P

Problem-based (P-type)

Real-world problems with known solution procedures but unpredictable outcomes (e.g., engineering simulations)

E

Evolutionary (E-type)

Embedded in the real world, must evolve as the environment changes (e.g., control systems, embedded software)

Electrical Engineering Context

Most electrical engineering software is E-type: power grid management systems, IoT device firmware, automotive control systems, and industrial automation software. These must continuously evolve as technologies, standards, and requirements change.

Law 1: Continuing Change

An E-type system must be continually adapted or it becomes progressively less satisfactory

Software that is used in a real-world environment must be continually updated to accommodate changes in that environment, new requirements, and to fix discovered defects.

Electrical Engineering Example

Electric vehicle charging station software must evolve to support new battery technologies, payment systems, safety standards, grid integration requirements, and communication protocols. Without updates, the stations become incompatible with newer vehicles and regulations.

Implications

Electrical engineers must design systems with adaptability in mind, using modular architectures, well-defined interfaces, and documentation that supports future maintainers.

Law 2: Increasing Complexity

As an E-type system evolves, its complexity increases unless work is done to maintain or reduce it

With each change, software tends to become more complex and difficult to understand. This increasing complexity makes future changes more expensive and error-prone.

Electrical Engineering Example

A satellite communication system's software started with basic modulation/demodulation functions. Over 10 years, features were added for encryption, error correction, adaptive beamforming, interference mitigation, and protocol updates. Without refactoring, the codebase becomes a tangled web of interdependencies.

Mitigation Strategies

Regular refactoring, complexity metrics monitoring, modular design, and thorough documentation can help manage complexity. Electrical engineers should apply principles like separation of concerns to hardware/software co-design.

Law 3: Self-Regulation

E-type system evolution is a self-regulating process

The evolution process distributes resources among activities (new features, defects fixing, restructuring) in a way that maintains an acceptable rate of progress across all areas.

Electrical Engineering Example

An industrial automation system's evolution naturally balances adding new production line controls (features), fixing sensor calibration issues (defects), and updating communication modules (adaptation). Development teams instinctively allocate resources to the most pressing needs based on user feedback and system performance.

Management Insight

Project managers should recognize this natural balancing and create processes that support rather than fight it. For electrical systems, this means maintaining flexibility in development schedules and resource allocation.

Law 4: Conservation of Organizational Stability

The average effective global activity rate in an evolving E-type system is invariant over the product's lifetime

There is a limit to how quickly a development organization can produce meaningful changes to a system. Adding more developers doesn't linearly increase output due to communication overhead and learning curves.

Electrical Engineering Example

A smart grid management system has a core team of 15 engineers. Doubling the team size to 30 doesn't double development speed because new members need time to understand the complex interactions between power flow algorithms, fault detection, and demand-response systems.

Practical Application

Electrical engineering projects should maintain stable, experienced teams. Knowledge retention through documentation and mentoring is crucial for long-term system evolution, especially for safety-critical systems.

Law 5: Conservation of Familiarity

The incremental growth in content of an E-type system is limited by the need to maintain familiarity

Significant changes to a system must be limited to preserve stakeholders' understanding. Large, rapid changes risk making the system unfamiliar to users, developers, and maintainers.

Electrical Engineering Example

When updating a programmable logic controller (PLC) system for a manufacturing plant, engineers cannot completely overhaul the control logic in one release. Operators need to recognize the system behavior, and maintenance technicians must understand troubleshooting procedures. Changes must be incremental.

Design Implication

For electrical control systems, maintain backward compatibility where possible, provide comprehensive change documentation, and phase in major changes gradually with adequate training for operators and technicians.

Law 6: Continuing Growth

The functional content of an E-type system must be continually increased to maintain user satisfaction over its lifetime

Users expect regular enhancements. If a system doesn't grow in functionality, users may perceive it as stagnant and look for alternatives, even if the current functionality meets their original needs.

Electrical Engineering Example

A home energy management system initially provided basic load monitoring. To keep customers engaged, the system evolved to include: predictive energy usage, integration with electric vehicles, demand response capabilities, renewable energy optimization, and detailed analytics. Each addition increased user satisfaction and retention.

Product Strategy

Electrical engineering products should have a clear roadmap for feature evolution. For IoT devices and smart systems, over-the-air update capabilities are essential to deliver ongoing value to customers.

Law 7: Declining Quality

The quality of an E-type system will appear to be declining unless it is rigorously maintained and adapted

As the environment changes and new requirements emerge, a system that remains unchanged will gradually become less effective. Quality is context-dependent and must be continually reassessed.

Electrical Engineering Example

A 4G cellular base station's software was initially high-quality. With the advent of 5G, new spectrum sharing techniques, security threats, and traffic patterns emerged. Without updates, the station's performance (quality) declined relative to newer stations with updated software, even though the hardware remained capable.

Quality Perspective

For electrical systems, quality metrics must evolve with the system. A power protection relay's "quality" in 2010 (fast tripping) differs from 2023 (fast tripping + cybersecurity + grid support functions). Regular updates are needed to maintain perceived quality.

Law 8: Feedback System

E-type evolution processes constitute multi-level, multi-loop, multi-agent feedback systems

Software evolution involves feedback loops at multiple levels: from users reporting issues, to developers implementing fixes, to testers verifying changes, to managers prioritizing work. These interconnected feedback loops drive the evolution process.

Electrical Engineering Example

An autonomous vehicle's software evolution involves: sensor feedback (hardware level), perception algorithm tuning (software level), driver reports (user level), regulatory requirements (societal level), and competitor analysis (market level). Changes at one level affect others in complex feedback relationships.

Systems Thinking

Electrical engineers should apply control theory principles to manage software evolution. Recognize feedback loops, implement appropriate gains (response rates), and avoid oscillations (overcorrection). This systems approach is natural for electrical engineers familiar with feedback control systems.

Implications for Software Engineering

Lehman's laws have profound implications for how we approach software engineering, especially for long-lived systems:

Evolution-Centric Design

Software architectures must support change through modularity, abstraction, and clear interfaces

Process Adaptation

Development processes must accommodate continuous change rather than assuming a "final" version

Metrics and Monitoring

Track complexity, technical debt, and evolution patterns to inform maintenance decisions

Knowledge Management

Preserve system familiarity through documentation, training, and gradual change introduction

"The laws suggest that software maintenance is not a phase but the dominant life cycle activity for most systems."

Applications in Electrical Engineering

How electrical engineers can apply Lehman's laws to their work:

Embedded Systems Design

Design firmware with field-upgrade capabilities, modular hardware abstraction layers, and versioned interfaces. Anticipate future sensor additions, communication protocol changes, and regulatory requirements.

Smart Grid Development

Grid management software must evolve with changing generation mixes (renewables), new load types (EVs), market structures, and cybersecurity threats. Implement adaptive control algorithms with parameter tuning capabilities.

Industrial Automation

Programmable Logic Controller (PLC) programs should be structured for evolution with clearly documented function blocks, standardized naming conventions, and version control. Plan for production line changes and new safety standards.

Automotive Systems

Electric vehicle software must support over-the-air updates for battery management improvements, new charging protocols, autonomous driving features, and regulatory compliance. Use adaptive software architectures.

Conclusion and Key Takeaways

Key Insights for Electrical Engineers

Most electrical engineering software is E-type and must evolve to remain useful
Evolution brings increasing complexity that must be actively managed
Design systems with evolution in mind from the beginning
Recognize the natural feedback systems in software evolution
Balance feature growth with complexity control and familiarity preservation
Allocate resources for ongoing maintenance and adaptation
Apply systems thinking from control theory to manage evolution processes

"For electrical engineers, understanding software evolution is no longer optional—it's essential for designing systems that will remain relevant and maintainable throughout their operational lifetimes."

References and Further Reading

Primary Sources

Lehman, M. M. (1980). Programs, Life Cycles, and Laws of Software Evolution. Proceedings of the IEEE.
Lehman, M. M., & Belady, L. A. (1985). Program Evolution: Processes of Software Change. Academic Press.
Lehman, M. M. (1996). Laws of Software Evolution Revisited. European Workshop on Software Process Technology.

Related Reading for Electrical Engineers

Bennett, K., & Rajlich, V. (2000). Software Maintenance and Evolution: A Roadmap. Future of Software Engineering.
Glass, R. L. (2002). Facts and Fallacies of Software Engineering. Addison-Wesley.
McConnell, S. (2004). Code Complete: A Practical Handbook of Software Construction. Microsoft Press.
Fowler, M. (2018). Refactoring: Improving the Design of Existing Code. Addison-Wesley.

Online Resources

IEEE Software Engineering Standards
ACM Digital Library - Software Evolution Research
Software Engineering Institute (SEI) Technical Reports
International Conference on Software Maintenance and Evolution (ICSME)

Thank You! Questions?