Namegames: Solving the hardest parts of Computer Science

46a19926f5dff95126e78b7393019c9e?s=47 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.

46a19926f5dff95126e78b7393019c9e?s=128

Andrew Hao

January 08, 2019
Tweet

Transcript

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

    Hao @andrewhao
  2. hi!

  3. “There are two hard things in computer science:
 
 naming,

    cache invalidation, and off-by-one errors”
  4. naming?

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

  6. semiotics the study of signs and symbols

  7. “rose”

  8. Signifier “rose” Signified flower

  9. love passion romance connotation

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

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

  12. cultural contexts shape meaning

  13. software semiotics

  14. Signifier User Account Signified Registered site visitor Personal preferences

  15. cultural contexts shape meaning

  16. business contexts shape meaning

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

  18. Signifier User Account Signified Credit card owner Credit card information

    Payment context
  19. Each business group has its own concepts vocabulary process(es) assumptions

    goals
  20. None
  21. None
  22. The invisible boundaries of culture & language

  23. We’re speaking different languages!

  24. Domain-driven naming

  25. None
  26. None
  27. None
  28. None
  29. Build a glossary

  30. A Glossary is a list of terms and definitions as

    thought about by the business
  31. None
  32. It is built collaboratively through conversation, and continually updated

  33. Pay down software name debt

  34. Make a commitment to rename and refactor your systems according

    to your new language
  35. Build boundaries

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

    (Subdomain)
  37. None
  38. Concepts & names can be precisely stated and free to

    evolve
  39. Getting to Alignment Business ↔ Domain Language ↔ Software

  40. A perfectly decent idea for naming

  41. Prefer Domain-Specific names over Flexibly Generic ones

  42. It’s not a… It’s a… AppointmentList Calendar Area SalesRegion Business

    Restaurant InvoiceManager BillingFlow
  43. How to manage change

  44. change: destroyer of systems

  45. 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.
  46. 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
  47. an employee leaves She knows things about the system nobody

    else does Anticipate her departure and collaboratively update the glossary & other documentation
  48. In summary

  49. 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.
  50. 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.
  51. Proactively manage change Change threatens to topple systems by introducing

    ambiguity Therefore: develop practices of updating documentation, sharing information and continually having conversations
  52. The summary of the summary

  53. See cultural boundaries Write it down Talk to business experts

    Change the code