Upgrade to Pro — share decks privately, control downloads, hide ads and more …

Wisdom of the Ancients

Nat Pryce
November 22, 2016

Wisdom of the Ancients

Presented at XP Day Germany 2016.

References:

Brooks F, The Mythical Man Month, Addison-Wesley, Reading, MA., 1975, 2nd ed. 1993

Lehman, M. M. 1980. “Programs,Life Cycles, and Laws of Software Evolution.” Proceedings of the IEEE 68 (9). IEEE Computer Society: 1060–76.

Lehman, M. M., and L. A. Belady. 1985. Program Evolution. Software: Practice and Experience. doi:10.1002/spe.4380161109.

Lehman, M. M. 1996. “Laws of Software Evolution Revisited.” Lecture Notes in Computer Science (Including Subseries Lecture Notes in Artificial Intelligence and Lecture Notes in Bioinformatics) 1149: 108–24. doi:10.1007/BFb0017737.

Herraiz, Israel, Daniel Rodriguez, Gregorio Robles, and Jesus M Gonzalez-Barahona. 2013. “The Evolution of the Laws of Software Evolution.” ACM Computing Surveys 46 (2): 1–28. doi:10.1145/2543581.2543595.

Parnas, D L, and P C Clements. 1986. “A Rational Design Process: How and Why to Fake It.” IEEE Trans. Softw. Eng. 12 (2): 251–57. doi:10.1109/TSE.1986.6312940.

Okakura, Kakuzo. 1904. The Book of Tea. Public domain. http://www.gutenberg.org/ebooks/769

Nat Pryce

November 22, 2016
Tweet

More Decks by Nat Pryce

Other Decks in Programming

Transcript

  1. Nat Pryce Wisdom of the Ancients [email protected] | @natpryce |

    github.com/npryce | speakerdeck.com/npryce
  2. … any program is a model of a model within

    a theory of a model of an abstraction of some portion of the world or of some universe of discourse. –Manny Lehman Programs, Life Cycles, and Laws of Evolution. 1980
  3. Lehman's categories of software system S-type formally defined by and

    derivable from a specification P-type solves a real-world problem but does not affect the world it models E-type embedded in the world it models; its operation changes that world
  4. Law of Continuous Change Any software system used in the

    real-world must change or become less and less useful in that environment. Law of Increasing Complexity As a system evolves, its complexity increases unless work is done to maintain or reduce it. –Manny Lehman (1974, ...)
  5. Evolution processes [of software systems] constitute multi level, multi loop,

    multi agent feedback systems –Manny Lehman (1974, ...)
  6. Principle of Uncertainty The outcome, in the real world, of

    software system operation is inherently uncertain with the precise area of uncertainty also unknown –Manny Lehman (1989)
  7. ... conceptual integrity is the most important consideration in system

    design. It is better to have a system omit certain anomalous features and improvements, but to reflect one set of design ideas, than to have one that contains many good but independent and uncoordinated ideas. –Fred Brooks The Mythical Man Month. 1975
  8. S-programs are … the programming form from which most advanced

    programming methodology and related techniques derive. –Manny Lehman (1980)
  9. 1974 Lehman's laws, from study of projects within IBM 1970

    1980 1990 2000 2020 2010 1990 Johnson & Opdyke's paper 1991 Griswold's PhD on restructuring functional & procedural code 1992 Opdyke's PhD on refactoring object-oriented code 1997 Smalltalk Refactoring Browser 1999 Refactoring by Fowler 1999 Roberts' PhD on the Smalltalk Refactoring Browser 2000 JetBrains Renamer for Java 2001 IntelliJ and Eclipse version 1 Refactoring tools: a prehistory 1984 Thinking Forth by Brodie
  10. ...as programming methodology evolves still further, all large programs (software

    systems) will be constructed as structures of S-programs. –Manny Lehman (1980)
  11. changes = internal quality feedback Refactor & abstract Eliminate source

    of developer error Refactor & abstract test results = external quality feedback System Test Automation instrumentation, bugs = external quality feedback How good are the tests?
  12. changes = internal quality feedback Refactor & abstract Eliminate source

    of developer error test results = external quality feedback instrumentation, bugs = external quality feedback difficulty testing = internal quality feedback Refactor & abstract System Test Automation How maintainable is the software?
  13. Eliminate source of developer error test results = external quality

    feedback instrumentation, bugs = external quality feedback difficulty testing = internal quality feedback Refactor & abstract changes = internal quality feedback System Test Automation Refactor & abstract How maintainable are the tests?
  14. changes = internal quality feedback instrumentation, bugs = external quality

    feedback difficulty testing = internal quality feedback Refactor & abstract Refactor & abstract test results = external quality feedback System Test Automation Eliminate source of developer error Can we eliminate the need for tests?
  15. changes = internal quality feedback instrumentation, bugs = external quality

    feedback difficulty testing = internal quality feedback Refactor & abstract Refactor & abstract test results = external quality feedback System Test Automation Eliminate source of developer error A cybernetic system
  16. Modernism Modernist [styles] shared certain underlying principles: a rejection of

    history and applied ornament; a preference for abstraction; and a belief that design and technology could transform society. http://www.vam.ac.uk/page/m/modernism/
  17. The dynamic nature of [Taoist and Zen] philosophy laid more

    stress upon the process through which perfection was sought than upon perfection itself. True beauty could be discovered only by one who mentally completed the incomplete. ... Uniformity of design was considered fatal to the freshness of imagination. –Kakuzo Okakura The Book of Tea, 1906
  18. N. Nagappan, A. Zeller, T. Zimmermann, K. Herzig, and B.

    Murphy. Change Bursts as Defect Predictors. 2010 “What happens if code changes again and again in some period of time? … Such change bursts have the highest predictive power for defect-prone components [and] significantly improve upon earlier predictors such as complexity metrics, code churn, or organizational structure.”
  19. Vielen Dank Thank you [email protected] | @natpryce | github.com/npryce |

    speakerdeck.com/npryce (who are hiring in London & Berlin) https://www.springernature.com/gp/group/careers Thanks to