Slide 1

Slide 1 text

Nat Pryce Wisdom of the Ancients [email protected] | @natpryce | github.com/npryce | speakerdeck.com/npryce

Slide 2

Slide 2 text

What it was like when I started

Slide 3

Slide 3 text

I spent very little of my time writing code

Slide 4

Slide 4 text

No content

Slide 5

Slide 5 text

… 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

Slide 6

Slide 6 text

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

Slide 7

Slide 7 text

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, ...)

Slide 8

Slide 8 text

Evolution processes [of software systems] constitute multi level, multi loop, multi agent feedback systems –Manny Lehman (1974, ...)

Slide 9

Slide 9 text

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)

Slide 10

Slide 10 text

... 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

Slide 11

Slide 11 text

How can we apply Lehman's insights?

Slide 12

Slide 12 text

1 Consider the system type when evaluating a technique or technology

Slide 13

Slide 13 text

S-programs are … the programming form from which most advanced programming methodology and related techniques derive. –Manny Lehman (1980)

Slide 14

Slide 14 text

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

Slide 15

Slide 15 text

...as programming methodology evolves still further, all large programs (software systems) will be constructed as structures of S-programs. –Manny Lehman (1980)

Slide 16

Slide 16 text

2 Nurture your feedback cycles

Slide 17

Slide 17 text

System Test Automation How good is the system? test results = external quality feedback

Slide 18

Slide 18 text

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?

Slide 19

Slide 19 text

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?

Slide 20

Slide 20 text

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?

Slide 21

Slide 21 text

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?

Slide 22

Slide 22 text

Tests Funnel diagram by http://unitydc.co.uk/funnels Refactor preventative measures to favour faster feedback The Funnel of Feedback

Slide 23

Slide 23 text

Types instead of Tests?!?!

Slide 24

Slide 24 text

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

Slide 25

Slide 25 text

3 Accept uncertainty

Slide 26

Slide 26 text

Why are developers uncomfortable with design as continual, gradual, never-ending adaption?

Slide 27

Slide 27 text

Weltanschauung

Slide 28

Slide 28 text

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/

Slide 29

Slide 29 text

Eames Chair

Slide 30

Slide 30 text

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

Slide 31

Slide 31 text

Wabi sabi, kintsugi bowl

Slide 32

Slide 32 text

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.”

Slide 33

Slide 33 text

1. Consider the system type 2. Nurture your feedback cycles 3. Accept uncertainty

Slide 34

Slide 34 text

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