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.

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
22. The invisible boundaries of culture & language
23. We’re speaking different languages!
24. Domain-driven naming
29. Build a glossary
30. A Glossary is a list of terms and definitions as thought about by the business
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)
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