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

Transcript

1. Nat Pryce Wisdom of the Ancients info@natpryce.com | @natpryce | github.com/npryce | speakerdeck.com/npryce
2. What it was like when I started
3. I spent very little of my time writing code
5. … 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
6. 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
7. 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, ...)
8. Evolution processes [of software systems] constitute multi level, multi loop, multi agent feedback systems –Manny Lehman (1974, ...)
9. 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)
10. ... 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
11. How can we apply Lehman's insights?
12. 1 Consider the system type when evaluating a technique or technology
13. S-programs are … the programming form from which most advanced programming methodology and related techniques derive. –Manny Lehman (1980)
14. 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
15. ...as programming methodology evolves still further, all large programs (software systems) will be constructed as structures of S-programs. –Manny Lehman (1980)
16. 2 Nurture your feedback cycles
17. System Test Automation How good is the system? test results = external quality feedback
18. 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?
19. 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?
20. 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?
21. 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?
22. Tests Funnel diagram by http://unitydc.co.uk/funnels Refactor preventative measures to favour faster feedback The Funnel of Feedback
23. Types instead of Tests?!?!
24. 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
25. 3 Accept uncertainty
26. Why are developers uncomfortable with design as continual, gradual, never-ending adaption?
27. Weltanschauung
28. 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/
29. Eames Chair
30. 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
31. Wabi sabi, kintsugi bowl
32. 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.”
33. 1. Consider the system type 2. Nurture your feedback cycles 3. Accept uncertainty
34. Vielen Dank Thank you info@natpryce.com | @natpryce | github.com/npryce | speakerdeck.com/npryce (who are hiring in London & Berlin) https://www.springernature.com/gp/group/careers Thanks to