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

The Most Dangerous Phrase

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.

Daniel Terhorst-North

May 18, 2023
Tweet

More Decks by Daniel Terhorst-North

Other Decks in Technology

Transcript

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

    View full-size slide

  2. CC-BY
    Disclaimer
    This is not a technical talk,

    this is a thinking talk

    with some technology in it!

    View full-size slide

  3. CC-BY
    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 full-size slide

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

    View full-size slide

  5. CC-BY
    Some ideas age well
    Others not so much

    View full-size slide

  6. CC-BY
    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?

    4. Which new rules will we need?

    View full-size slide

  7. CC-BY
    “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?
    What does “ageing well” mean?

    View full-size slide

  8. CC-BY
    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, di
    ff
    erent old people have di
    ff
    erent stories

    Don’t believe any single source, not even me!
    Which limitation does the technology diminish?

    View full-size slide

  9. CC-BY
    When good advice turns bad
    Single Responsibility Principle

    Open-Closed Principle

    Liskov Substitutability Principle

    Interface Segregation Principle

    Dependency Inversion Principle

    View full-size slide

  10. CC-BY
    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 full-size slide

  11. CC-BY
    void render(calc) {

    }
    Calc doCalc(data) {

    }
    Data getData() {

    }
    Single Responsibility Principle
    void printReport() {
    }
    calc = doCalc(data);
    data = getData();
    render(calc);

    View full-size slide

  12. CC-BY
    Calc doCalc(data) {

    }
    Data getData() {

    }
    void render(calc) {

    }
    Single Responsibility Principle
    void printReport() {
    }
    calc = doCalc(data);
    data = getData();
    render(calc);

    View full-size slide

  13. CC-BY
    Data getData() {

    }
    Single Responsibility Principle
    void printReport() {
    }
    calc = doCalc(data);
    data = getData();
    render(calc);
    Calc doCalc(data) {

    }
    void render(calc) {

    }

    View full-size slide

  14. CC-BY
    Data getData() {

    }
    Single Responsibility Principle
    void printReport() {
    }
    calc = doCalc(data);
    data = getData();
    render(calc);
    Add a
    fi
    eld?
    Change the
    precision?
    Calc doCalc(data) {

    }
    void render(calc) {

    }
    ?

    View full-size slide

  15. CC-BY
    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 full-size slide

  16. CC-BY
    Separation Of Concerns
    Holistic, e.g. correct vs e
    ffi
    cient

    “…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
    ff
    i
    ciently complicated
    to require such a separation of concerns.”
    — E. W. Dijkstra, On the Role of Scienti
    fi
    c Thought, 1974

    View full-size slide

  17. CC-BY
    Let’s actually separate concerns!
    Behaviour is a concern; code structure is a separate concern

    Keep all the code together while it Fits In My* Head

    ✴ where My Head knows the language, toolchain, idioms, problem domain

    Only then “gather together things that change together”!

    - assume programmers are polyglot and that changes a
    ff
    ect the whole stack

    - self-contained sub-reports rather than ReportViews, ReportModels, etc.

    View full-size slide

  18. CC-BY
    HTMX: a counterpoint
    “Why should only and make HTTP requests?

    “Why should only click and submit trigger them?

    “Why should only GET and POST methods be available?

    “Why should you replace the entire window?

    “By removing these arbitrary constraints, htmx completes
    HTML as a hypertext.”
    https://htmx.org/essays

    View full-size slide

  19. CC-BY
    HTMX: a counterpoint
    hx-trigger="click"
    hx-target=“#parent-div”
    hx-swap=“outerHTML"
    >
    Click Me!

    https://htmx.org/essays

    View full-size slide

  20. CC-BY
    “The most dangerous
    phrase you can use
    is ‘We’ve always
    done it that way.’”
    — Admiral Grace Hopper

    View full-size slide

  21. CC-BY
    Open-Closed Principle
    “A class should be open for extension, closed for
    modi
    fi
    cation.”

    Answers the question: “But what happens if..?”

    Two
    fl
    avours

    - Bertrand Meyer uses abstract classes

    - Robert Martin uses interfaces

    View full-size slide

  22. CC-BY
    Open-Closed Principle
    Source code was an 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 full-size slide

  23. CC-BY
    Open-Closed Principle
    1999 2001
    2000 2010

    View full-size slide

  24. CC-BY
    Open-Closed Principle
    Changing code became easy and deterministic!

    - The IDE refactored code under your
    fi
    ngers

    - TDD enabled iterative design; test automation provided feedback

    - deterministic build pipelines meant we could
    fi
    x forward

    Services became the asset!

    - You would integrate with a SaaS through its API

    - no abstract classes were harmed

    All code was both open and closed, all the time!

    - code became malleable, not assembled chunks

    View full-size slide

  25. CC-BY
    “The most dangerous
    phrase you can use
    is ‘We’ve always
    done it that way.’”
    — Admiral Grace Hopper

    View full-size slide

  26. CC-BY
    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 full-size slide

  27. CC-BY
    Scrum
    Started* 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 emerged

    - multi-year release became 6-week Sprints

    - detailed Gantt chart became lightweight Sprint Plan

    - multi-month features became vertical Backlog items

    - monthly steering became daily Scrum

    - Business Requirements Document became Backlog of desired items

    - time-consuming hand-o
    ff
    s became Dev Team
    fl
    ic.kr/p/9LLNfg

    View full-size slide

  28. CC-BY
    Scrum
    No one could believe what they are seeing!

    - Delivering within a quarter was “impossible”

    - Hardware procurement took months

    - Compiling and linking code took hours

    Two pioneers of Scrum wrote the Guide

    - Certi
    fi
    cation provided a direct lineage to real practitioners

    Scrum exploded into a $billion certi
    fi
    cation industry

    - eclipsed all other Agile methods, became synonymous with “Agile”
    xkcd.com/

    View full-size slide

  29. CC-BY
    In the 30 years since…

    Technical landscape has evolved beyond recognition

    - Languages that compile in milliseconds

    - Continuous Delivery from check-in to tested, live 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!)
    Scrum

    View full-size slide

  30. CC-BY
    A modern alternative to Scrum
    Two planning cadences: quarterly OKRs and in the moment

    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 full-size slide

  31. CC-BY
    Why do we cling to obsolete technology?
    Commitment & Consistency Bias

    - “No one ever got
    fi
    red…”

    Mindshare, money accrete over time

    - Do not assume malice or greed, just structural inertia

    Bounded rather than centred communities

    - Boundary prevents evolution

    - Tweaking for “clari
    fi
    cation”

    - Gatekeeping by the founders

    View full-size slide

  32. CC-BY
    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 full-size slide

  33. CC-BY
    “The most dangerous
    phrase you can use
    is ‘We’ve always
    done it that way.’”
    — Admiral Grace Hopper

    View full-size slide

  34. CC-BY
    https://dannorth.net

    [email protected]

    @tastapod

    @[email protected]

    Come and
    fi
    nd me!
    Thank you

    View full-size slide