The Most Dangerous Phrase

Some advice is timeless; it ages like a fine wine. Each time you revisit it you discover a nuance, a new connection to something else. As you grow, the advice is waiting there to reveal another layer you had never considered.

Some advice is a product of its time; it ages like milk. It starts fresh, then it begins to smell, and eventually it rots and can even become harmful! It made sense in the context and constraints of its day, but things have changed and it is no longer relevant.

As Admiral Grace Hopper famously said: "The most dangerous phrase you can use is 'But we've always done it this way!'" Daniel believes this is why so many people have an almost religious zeal for SOLID, Scrum, and other antiquities.

In this session, Daniel argues from first principles why ideas like SOLID and Scrum made sense in their day, over a quarter century ago, and why they have been superseded and should now be considered harmful. For contrast, he suggests Continuous Delivery and lean product development are ageing like fine wines. If there is time, he will show how methods like SAFe have never been relevant and never will be, but can be very appealing to a certain kind of manager.

Transcript

1. “The most dangerous phrase”
   Daniel Terhorst-North presents…
   …featuring SOLID, Scrum, and other antiquities
   

   View Slide

2. @tastapod
   Disclaimer
   This is not a technical talk,
   
   this is a thinking talk
   
   with some technology in it!
   

   View Slide

3. @tastapod
   Why do we do what we do?
   Out of habit
   
   Because it is “obviously right”
   
   Because this is the way I was taught
   
   Because everyone else does it this way
   
   Because we’ve always done it this way
   

   View Slide

4. @tastapod
   “The most dangerous
   phrase you can use
   is ‘We’ve always
   done it that way.’”
   — Admiral Grace Hopper
   

   View Slide

5. @tastapod
   Some ideas age well
   Others not so much
   

   View Slide

6. @tastapod
   What does “ageing well” mean?
   “Technology can bring bene
   fi
   ts if, and only if,

   it diminishes a limitation.”
   1. What is the power of the technology?
   
   2. Which limitation does the technology diminish?
   
   3. Which rules enabled us to manage this limitation?
   
   4. Which new rules will we need?
   

   View Slide

7. @tastapod
   What does “ageing well” mean?
   “Technology can bring bene
   fi
   ts if, and only if,

   it diminishes a limitation.”
   1. What is the power of the technology?
   
   2. Which limitation does the technology diminish?
   
   3. How has that limitation changed since?
   
   4. What should we be doing instead?
   

   View Slide

8. @tastapod
   Which limitation does the technology diminish?
   It helps to understand the context
   
   Talk to old people (who were there)
   
   I am old people, talk to me!
   
   Not gatekeeping, just getting closer to the source
   
   Remember, old people have di
   ff
   erent stories
   
   Don’t believe any single source, not even me!
   

   View Slide

9. @tastapod
   When good advice turns bad
   Single Responsibility Principle
   
   Open-Closed Principle
   
   Liskov Substitutability Principle
   
   Interface Segregation Principle
   
   Dependency Inversion Principle
   

   View Slide

10. @tastapod
    Single Responsibility Principle
    “A class should have only one reason to change [or serve one actor]”
    
    “Gather together the things that change for the same reasons. Separate
    those things that change for di
    ff
    erent reasons.”
    
    “[T]he role of an accountant is di
    ff
    erent from a database administrator.”
    
    “This is the reason we do not put SQL in JSPs. This is the reason we do not
    generate HTML in the modules that compute results. This is the reason that
    business rules should not know the database schema. This is the reason we
    separate concerns.”
    

    View Slide

11. @tastapod
    Single Responsibility Principle
    public void printReport() {
    
    
    }
    data = getData();
    calc = doCalc(data);
    render(calc);
    

    View Slide

12. @tastapod
    Single Responsibility Principle
    public void printReport() {
    
    
    }
    data = getData();
    calc = doCalc(data);
    render(calc);
    public Calc doCalc(Data data) {
    
    
    …
    
    
    }
    public void render(Calc calc) {
    
    
    …
    
    
    }
    public Data getData() {
    
    
    …
    
    
    }
    

    View Slide

13. @tastapod
    Single Responsibility Principle
    public void printReport() {
    
    
    }
    data = getData();
    calc = doCalc(data);
    render(calc);
    public Data getData() {
    
    
    …
    
    
    }
    public Calc doCalc(Data data) {
    
    
    …
    
    
    }
    public void render(Calc calc) {
    
    
    …
    
    
    }
    

    View Slide

14. @tastapod
    Single Responsibility Principle
    public void printReport() {
    
    
    }
    data = getData();
    calc = doCalc(data);
    render(calc);
    ?
    Add a
    fi
    eld?
    Change the
    precision?
    public Calc doCalc(Data data) {
    
    
    …
    
    
    }
    public void render(Calc calc) {
    
    
    …
    
    
    }
    public Data getData() {
    
    
    …
    
    
    }
    

    View Slide

15. @tastapod
    Single Responsibility Principle
    app
    
    
    ├── assets
    
    
    │ ├── config
    
    
    │ ├── images
    
    
    │ └── stylesheets
    
    
    ├── channels
    
    
    │ └── application_cable
    
    
    ├── controllers
    
    
    │ └── concerns
    
    
    ├── helpers
    
    
    ├── javascript
    
    
    │ └── controllers
    
    
    ├── jobs
    
    
    ├── mailers
    
    
    ├── models
    
    
    │ └── concerns
    
    
    └── views
    
    
    └── layouts
    Logical conclusion:
    
    Ruby on Rails
    
    “Separation of Concerns” [abridged]
    

    View Slide

16. @tastapod
    Separation of Concerns
    “…being one- and multiple-track minded simultaneously.
    “The task of ‘making a thing satisfying our needs’ is split into two parts
    ‘stating the properties of a thing’ and ‘making a thing guaranteed to have the
    stated properties’.
    “Business data processing systems are su
    ffi
    ciently complicated to require
    such a separation of concerns.”
    — E. W. Dijkstra, On the Role of Scienti
    fi
    c Thought, 1974
    Holistic, e.g. correct vs e
    ff i
    cient
    

    View Slide

17. @tastapod
    Let’s actually separate concerns!
    Behaviour is a concern; code structure is a separate concern
    
    Keep all the code together while it Fits In Your* Head
    
    - *where Your Head understand the language, its toolchain, its idioms, the problem domain
    
    Only then, move the code to “gather together things that change together”!
    
    - assume that programmers are polyglot and that changes a
    ff
    ect the whole stack
    
    - self-contained sub-reports rather than ReportViews, ReportModels, etc.
    

    View Slide

18. @tastapod
    HTMX: a counterpoint
    Motivation:
    
    Why should only and be able to make HTTP
    requests?
    Why should only click and submit events trigger them?
    Why should only GET and POST methods be available?
    Why should you only be able to replace the entire [page]?
    By removing these arbitrary constraints, htmx completes
    HTML as a hypertext.
    
    
    hx-trigger="click"
    
    
    hx-target="#parent-div"
    
    
    hx-swap="outerHTML"
    
    
    >
    
    
    Click Me!
    
    
    
    https://htmx.org/essays
    

    View Slide

19. @tastapod
    “The most dangerous
    phrase you can use
    is ‘We’ve always
    done it that way.’”
    — Admiral Grace Hopper
    

    View Slide

20. @tastapod
    Open-Closed Principle
    “A class should be open for extension, closed for modi
    fi
    cation.”
    
    Answers the question: “But what happens if..?” [we add a new case]
    
    Two
    fl
    avours
    
    - Bertrand Meyer uses abstract classes
    
    - Robert Martin uses interfaces
    

    View Slide

21. @tastapod
    Open-Closed Principle
    Source code was the asset
    
    - You would sell a specialised source library for e.g. healthcare or
    fi
    nance
    
    - Clear extension points so the customer wouldn’t mess up the internals
    
    Changing code was risky
    
    - poor tooling for deterministic code changes
    
    - little automated testing in the C++ or Enterprise Java cultures
    

    View Slide

22. @tastapod
    Open-Closed Principle
    1999 2001
    2000
    

    View Slide

23. @tastapod
    Open-Closed Principle
    Changing code becomes easy and deterministic!
    
    - The IDE manipulates code through its AST under your
    fi
    ngers
    
    - TDD code examples act as
    fi
    rst line checking; automated testing helps further
    
    - atomic version control means backing out changes is trivial*
    
    Services are now the asset!
    
    - You integrate with a SaaS through its API
    
    - no abstract classes were harmed
    
    All code is both open and closed, all the time!
    
    - code is malleable, not assembled chunks
    

    View Slide

24. @tastapod
    “The most dangerous
    phrase you can use
    is ‘We’ve always
    done it that way.’”
    — Admiral Grace Hopper
    

    View Slide

25. @tastapod
    The others are left as an exercise*
    Single Responsibility Principle
    
    Open-Closed Principle
    
    Liskov Substitutability Principle
    
    Interface Segregation Principle
    
    Dependency Inversion Principle
    *or read “CUPID—the back story”
    

    View Slide

26. @tastapod
    Scrum
    Starts* in the early 1990s with a single constraint
    
    - Martine Devos: deliver something in 12 weeks with

    a checkpoint at 6 weeks (“sprint to halfway”)
    
    Novel practices emerge
    
    - the 6-week Sprint itself
    
    - multi-year Gantt chart becomes lightweight Sprint Plan
    
    - multi-month features become vertical Backlog items
    
    - monthly steering becomes daily Scrum
    
    - comprehensive Business Requirements Document becomes Backlog of desired items
    
    - time-consuming hand-o
    ff
    s become Dev Team
    fl
    ic.kr/p/9LLNfg
    

    View Slide

27. @tastapod
    Scrum
    No one can believe what they are seeing!
    
    - Delivering within a quarter is “impossible”
    
    - Hardware procurement takes months, provisioning takes weeks
    
    - Compiling code takes hours, deployment even longer
    
    Two of the originators of Scrum write the Guide
    
    - Certi
    fi
    cation provides a direct lineage to real practitioners
    
    Scrum explodes into a $billion certi
    fi
    cation industry
    
    - eclipses all other Agile methods, becomes synonymous with “Agile”
    xkcd.com/303
    

    View Slide

28. @tastapod
    Scrum
    In the 30 years since…
    
    Technical landscape has evolved beyond recognition
    
    - Languages that compile in milliseconds
    
    - Continuous Delivery from source code check-in to tested, running system
    
    - Procurement and provisioning of compute infrastructure on demand
    
    - Web deployment and beta app channels enable rapid and rich user feedback
    
    Scrum moved the game from years to months or weeks
    
    - now it moves the game from minutes to months or weeks
    
    - solves for problems that no longer exist (except where they do!)
    

    View Slide

29. @tastapod
    A modern alternative to Scrum
    Two planning cadences: quarterly OKRs and in the moment (continually)
    
    Organise teams around anticipated demand
    
    - As
    fl
    uid as the demand is dynamic, quarterly re-teaming
    
    - Some people not even in teams!
    
    Deployment is a technical decision, release is a commercial one
    
    Daily steering is about what is left, not what is done
    

    View Slide

30. @tastapod
    Why do we cling to obsolete technology?
    Momentum, mindshare, money accrete over time
    
    - Do not assume malice or greed, just structural inertia
    
    Commitment & Consistency Bias
    
    - “No one ever got
    fi
    red…”
    
    Bounded rather than centred communities
    
    - Boundary prevents evolution
    
    - Tweaking for “clari
    fi
    cation”
    
    - Gatekeeping by the founders
    

    View Slide

31. @tastapod
    Look past the Scrum and SOLID dogma
    
    Assess your own tools & practices
    
    - Which should you change, and towards what?
    
    Talk to some old people
    
    - and remember, I am old people!
    “You must think for yourselves!”
    

    View Slide

32. @tastapod
    “The most dangerous
    phrase you can use
    is ‘We’ve always
    done it that way.’”
    — Admiral Grace Hopper
    

    View Slide