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

Namegames: Solving the hardest parts of Computer Science

Andrew Hao
January 08, 2019

Namegames: Solving the hardest parts of Computer Science

The hardest problems in CS are in naming. Let's take a cue from communication studies and apply Semiotics to our software systems. Then we'll look at how DDD helps us develop modular software systems that are built to evolve with the business.

Andrew Hao

January 08, 2019
Tweet

More Decks by Andrew Hao

Other Decks in Programming

Transcript

  1. Namegames
    Cracking the hardest problems in computer
    science (seriously)
    Andrew Hao @andrewhao

    View full-size slide

  2. “There are two hard things in
    computer science:


    naming,
    cache invalidation, and
    off-by-one errors”

    View full-size slide

  3. (good) naming
    = readability
    = ⚒ high maintainability

    View full-size slide

  4. semiotics
    the study of signs and symbols

    View full-size slide

  5. Signifier
    “rose”
    Signified
    flower

    View full-size slide

  6. love
    passion
    romance
    connotation

    View full-size slide

  7. Signifier
    “rose”
    Signified
    love, passion,
    romance

    View full-size slide

  8. Signifier
    “rose”
    Signified
    ???
    Non-Western contexts?

    View full-size slide

  9. cultural
    contexts
    shape
    meaning

    View full-size slide

  10. software
    semiotics

    View full-size slide

  11. Signifier
    User
    Account
    Signified
    Registered site
    visitor
    Personal
    preferences

    View full-size slide

  12. cultural
    contexts
    shape
    meaning

    View full-size slide

  13. business
    contexts
    shape
    meaning

    View full-size slide

  14. Signifier
    User
    Account
    Signified
    Inbound visitor
    Email preferences
    Marketing context

    View full-size slide

  15. Signifier
    User
    Account
    Signified
    Credit card owner
    Credit card
    information
    Payment context

    View full-size slide

  16. Each business group has its own
    concepts
    vocabulary
    process(es)
    assumptions
    goals

    View full-size slide

  17. The invisible boundaries of culture &
    language

    View full-size slide

  18. We’re speaking different languages!

    View full-size slide

  19. Domain-driven
    naming

    View full-size slide

  20. Build a
    glossary

    View full-size slide

  21. A Glossary is a list of terms and
    definitions as thought about by the
    business

    View full-size slide

  22. It is built collaboratively through
    conversation, and continually updated

    View full-size slide

  23. Pay down
    software
    name debt

    View full-size slide

  24. Make a commitment to rename and
    refactor your systems according to
    your new language

    View full-size slide

  25. Build
    boundaries

    View full-size slide

  26. Build a software boundary (Bounded
    Context) around each business unit
    (Subdomain)

    View full-size slide

  27. Concepts & names can be precisely
    stated and free to evolve

    View full-size slide

  28. Getting to Alignment
    Business ↔ Domain Language ↔ Software

    View full-size slide

  29. A perfectly
    decent idea
    for naming

    View full-size slide

  30. Prefer
    Domain-Specific names
    over
    Flexibly Generic ones

    View full-size slide

  31. It’s not a… It’s a…
    AppointmentList Calendar
    Area SalesRegion
    Business Restaurant
    InvoiceManager BillingFlow

    View full-size slide

  32. How to
    manage
    change

    View full-size slide

  33. change: destroyer of systems

    View full-size slide

  34. the business pivots
    Old concepts need to be supported,
    but are no longer currently
    applicable.
    Draft up a plan to deprecate old
    classes, modules, concepts.

    View full-size slide

  35. another team joins the fray
    Not everyone has the same conceptual
    model; drift occurs in naming and
    concepts
    Consistently talk about naming in
    architecture meetings and code reviews

    View full-size slide

  36. an employee leaves
    She knows things about the system
    nobody else does
    Anticipate her departure and
    collaboratively update the glossary &
    other documentation

    View full-size slide

  37. Applying semiotics to software
    Meaning in software systems is
    constructed through a business-
    cultural lens
    Therefore: view your system as a
    federation of cultures.
    Develop an independent, documented
    vocabulary for each business context.

    View full-size slide

  38. Align software to the business
    Clean systems map directly to business
    contexts
    Therefore: Update systems to cleanly
    use domain language.
    Modularize systems to independently
    operate in each business unit.

    View full-size slide

  39. Proactively manage change
    Change threatens to topple systems by
    introducing ambiguity
    Therefore: develop practices of
    updating documentation, sharing
    information and continually having
    conversations

    View full-size slide

  40. The summary
    of the
    summary

    View full-size slide

  41. See cultural
    boundaries

    Write it
    down

    Talk to business
    experts

    Change the
    code

    View full-size slide