What Comes After SOLID? Seeking Holistic Software Quality

You care deeply about code quality and constantly strive to learn more. You devour books and blogs, watch conference talks, and practice code katas.

That's excellent! But immaculately factored code and clean architecture alone won't guarantee quality software.

As a developer, your job isn't to write Good Code. It's to deliver value for people. In that light, we'll examine the effects of a host of popular coding practices. What do they accomplish? Where do they fall short?

We'll set meaningful goals for well-rounded, high-quality software that solves important problems for real people.

Transcript

1. What Comes After SOLID? SEEKING HOLISTIC SOFTWARE QUALITY
3. TRANSLATING “HAVE TO” TO “CHOOSE TO”
4. I CHOOSE TO __________ BECAUSE I WANT _________
5. I CHOOSE TO ✍ BECAUSE I WANT _________
6. I CHOOSE TO ✍ BECAUSE I WANT ???????????
7. WHY DO WE CARE ABOUT WRITING GOOD CODE?
8. IS GOOD CODE THE SAME AS QUALITY SOFTWARE?
9. (WE’LL GET BACK TO THAT…)
10. “AGILE” IS BROKEN ACCORDING TO DAVE THOMAS, ROBERT MARTIN, AND OTHERS:
11. AT THAT 2001 MEETING IN SNOWBIRD WHERE WE WROTE THE AGILE MANIFESTO, KENT BECK STATED ONE OF OUR GOALS: "..TO HEAL THE DIVIDE BETWEEN DEVELOPMENT AND BUSINESS." Robert C. Martin https://8thlight.com/blog/uncle-bob/2014/03/28/The-Corruption-of-Agile.html
12. IT DIDN’T WORK THE GRIM REALITY:
13. SOMETHING DEVELOPERS DO TO KEEP BUSINESSPEOPLE HAPPY “AGILE” HAS BECOME
15. WE DON’T NEED MORE PROCESSES. WE DO NEED MORE TRUST.
16. WE CAN SOLVE THIS IF WE LEARN TO COMMUNICATE
17. CREATE A COMMON LANGUAGE FOR DEVELOPERS AND BUSINESSPEOPLE OUR GOAL TODAY IS AMBITIOUS
18. FIGURING OUT WHY WE WRITE GOOD CODE WE’LL ACHIEVE IT BY
19. WHY WRITE CODE? LIKE, EVER? I’M NOT KIDDING.
20. YOUR JOB ISN’T TO WRITE CODE. CONTROVERSIAL STATEMENT #1 YOUR JOB IS TO SOLVE PROBLEMS.
21. YOUR JOB ISN’T TO WRITE CODE. YOUR JOB IS TO CREATE VALUE. BUSINESS TRANSLATION
22. CREATING VALUE VALUE CREATION ALWAYS MEANS 1 OF 3 THINGS: ▸ Generating Revenue ▸ Lowering Costs ▸ Reducing Risk
23. WHY WRITE CODE? TO CREATE VALUE. THAT’S IT.
24. WHY DO WE CARE ABOUT WRITING GOOD CODE?
25. GOOD CODE USUALLY HELPS TO CREATE VALUE.
26. IS GOOD CODE THE SAME AS QUALITY SOFTWARE?
27. NOPE.
28. SOFTWARE QUALITY IS BEST DEFINED AS THE AMOUNT OF VALUE IT CREATES. CONTROVERSIAL STATEMENT #2
29. HOW CAN WE TARGET EFFORTS TO MAXIMIZE VALUE CREATION?
30. HOW CAN WE RELATE GOOD CODE TO VALUE CREATION?
31. THE FRAMEWORK SOFTWARE QUALITY CAN BE DISTILLED INTO 3 FACTORS: ▸ Usefulness ▸ Sustainability ▸ Accuracy
32. THE FRAMEWORK USEFULNESS ▸ The Question ▸ Does it solve a problem effectively? ▸ The Target ▸ Users ▸ Is this a problem that affects users? ▸ Does the product solve their problem? ▸ In a way that works for them?
33. THE FRAMEWORK SUSTAINABILITY ▸ The Question ▸ Can we keep building without unnecessary obstacles? ▸ The Targets ▸ Software ▸ Is it resistant to change? ▸ Will we understand what it does later? ▸ Does the architecture resist new functionality? ▸ The Development Team ▸ Is the Team unstable in a way that will prevent future progress?
34. THE FRAMEWORK ACCURACY ▸ The Question ▸ Does it work the way we think it does? ▸ The Target ▸ Ourselves ▸ Have we developed understanding of the problem? ▸ Have we developed understanding of the code? ▸ Is there cognitive overload preventing understanding? ▸ Are we confident that the code reflects our current understanding?
35. I CHOOSE TO WRITE GOOD CODE BECAUSE I WANT U.S.A. SOFTWARE
36. Usefulness Business Analysts Product
 Designers
 UX Accuracy Developers Sustainability Developers THE TRADITIONAL MODEL WHAT WE ACTUALLY NEED
37. Usefulness Business Analysts Product
 Designers
 UX Developers Accuracy Developers Sustainability Developers WHAT WE ACTUALLY NEED
38. ACCURATE DOES IT WORK
 THE WAY WE THINK IT DOES? USEFUL
 DOES IT SOLVE
 A REAL PROBLEM
 EFFECTIVELY? SUSTAINABLE CAN WE KEEP
 BUILDING WITHOUT
 UNNECESSARY
 OBSTACLES? DOES IT WORK
 FOR OUR USERS
 AS THEY EXPECT? CAN WE KEEP BUILDING OUR SYSTEM WITHOUT BREAKING OUR SYSTEM? ARE THERE
 OBSTACLES TO
 FUTURE USEFULNESS? IS IT
 QUALITY
 SOFTWARE?
39. IS IT QUALITY SOFTWARE? CLASSIFYING SOLID ▸ Single Responsibility Principle ▸ Every element of a system should do one thing well ▸ Open/Closed Principle ▸ Possible to add new features without modifying existing code ▸ Liskov Substitution Principle ▸ Subclasses should fully implement their superclasses ▸ Interface Segregation Principle ▸ Limit the surface area of objects’ dependencies on other objects ▸ Dependency Inversion Principle ▸ Depend on abstractions, not concretions
40. Usefulness Accuracy Sustainability Single Responsibility Open/Closed Liskov Substitution Interface Segregation Dependency Inversion Usefulness Accuracy Sustainability Single Responsibility ✅ ✅ ✅ Open/Closed ❌ ❌ ✅ Liskov Substitution ❌ ✅ ✅ Interface Segregation ❌ ❌ ✅ Dependency Inversion ❌ ❌ ✅ IS IT QUALITY SOFTWARE? CLASSIFYING SOLID
41. ACCURATE DOES IT WORK
 THE WAY WE THINK IT DOES? USEFUL
 DOES IT SOLVE
 A REAL PROBLEM
 EFFECTIVELY? SUSTAINABLE CAN WE KEEP
 BUILDING WITHOUT
 UNNECESSARY
 OBSTACLES? LISKOV SUBSTITUTION OPEN/CLOSED PRINCIPLE INTERFACE SEGREGATION DOES IT WORK
 FOR OUR USERS
 AS THEY EXPECT? CAN WE KEEP BUILDING OUR SYSTEM WITHOUT BREAKING OUR SYSTEM? ARE THERE
 OBSTACLES TO
 FUTURE USEFULNESS? IS IT
 QUALITY
 SOFTWARE? DEPENDENCY INVERSION SRP
42. ACCURATE DOES IT WORK
 THE WAY WE THINK IT DOES? USEFUL
 DOES IT SOLVE
 A REAL PROBLEM
 EFFECTIVELY? SUSTAINABLE CAN WE KEEP
 BUILDING WITHOUT
 UNNECESSARY
 OBSTACLES? LISKOV SUBSTITUTION OPEN/CLOSED PRINCIPLE INTERFACE SEGREGATION DOES IT WORK
 FOR OUR USERS
 AS THEY EXPECT? CAN WE KEEP BUILDING OUR SYSTEM WITHOUT BREAKING OUR SYSTEM? ARE THERE
 OBSTACLES TO
 FUTURE USEFULNESS? IS IT
 QUALITY
 SOFTWARE? DEPENDENCY INVERSION SRP
43. IS IT QUALITY SOFTWARE? SANDI METZ’S TRUE PRINCIPLES ▸ Transparent ▸ Consequences of changing code should be obvious ▸ Reasonable ▸ Cost of change should be proportional to its benefits ▸ Usable ▸ Existing code should be usable in new and unexpected contexts ▸ Exemplary ▸ Code should encourage future coders to perpetuate good qualities
44. ACCURATE DOES IT WORK
 THE WAY WE THINK IT DOES? USEFUL
 DOES IT SOLVE
 A REAL PROBLEM
 EFFECTIVELY? SUSTAINABLE CAN WE KEEP
 BUILDING WITHOUT
 UNNECESSARY
 OBSTACLES? LISKOV SUBSTITUTION OPEN/CLOSED PRINCIPLE INTERFACE SEGREGATION DOES IT WORK
 FOR OUR USERS
 AS THEY EXPECT? CAN WE KEEP BUILDING OUR SYSTEM WITHOUT BREAKING OUR SYSTEM? ARE THERE
 OBSTACLES TO
 FUTURE USEFULNESS? IS IT
 QUALITY
 SOFTWARE? DEPENDENCY INVERSION REUSABLE EXEMPLARY REASONABLE TRANSPARENT SRP
45. ACCURATE DOES IT WORK
 THE WAY WE THINK IT DOES? USEFUL
 DOES IT SOLVE
 A REAL PROBLEM
 EFFECTIVELY? SUSTAINABLE CAN WE KEEP
 BUILDING WITHOUT
 UNNECESSARY
 OBSTACLES? LISKOV SUBSTITUTION OPEN/CLOSED PRINCIPLE INTERFACE SEGREGATION DOES IT WORK
 FOR OUR USERS
 AS THEY EXPECT? CAN WE KEEP BUILDING OUR SYSTEM WITHOUT BREAKING OUR SYSTEM? ARE THERE
 OBSTACLES TO
 FUTURE USEFULNESS? IS IT
 QUALITY
 SOFTWARE? DEPENDENCY INVERSION REUSABLE EXEMPLARY REASONABLE TRANSPARENT SRP
46. IS IT QUALITY SOFTWARE? TESTING ▸ Testing at all ▸ Code Coverage ▸ Types of tests ▸ Unit ▸ Integration ▸ Manual QA ▸ Test-Driven Development ▸ Behavior-Driven Development
47. ACCURATE DOES IT WORK
 THE WAY WE THINK IT DOES? USEFUL
 DOES IT SOLVE
 A REAL PROBLEM
 EFFECTIVELY? SUSTAINABLE CAN WE KEEP
 BUILDING WITHOUT
 UNNECESSARY
 OBSTACLES? LISKOV SUBSTITUTION OPEN/CLOSED PRINCIPLE INTERFACE SEGREGATION DOES IT WORK
 FOR OUR USERS
 AS THEY EXPECT? CAN WE KEEP BUILDING OUR SYSTEM WITHOUT BREAKING OUR SYSTEM? ARE THERE
 OBSTACLES TO
 FUTURE USEFULNESS? IS IT
 QUALITY
 SOFTWARE? DEPENDENCY INVERSION REUSABLE EXEMPLARY REASONABLE TRANSPARENT UNIT TESTS TDD COVERAGE SRP TESTING INTEGRATION TESTS BDD MANUAL QA
48. ACCURATE DOES IT WORK
 THE WAY WE THINK IT DOES? USEFUL
 DOES IT SOLVE
 A REAL PROBLEM
 EFFECTIVELY? SUSTAINABLE CAN WE KEEP
 BUILDING WITHOUT
 UNNECESSARY
 OBSTACLES? LISKOV SUBSTITUTION OPEN/CLOSED PRINCIPLE INTERFACE SEGREGATION DOES IT WORK
 FOR OUR USERS
 AS THEY EXPECT? CAN WE KEEP BUILDING OUR SYSTEM WITHOUT BREAKING OUR SYSTEM? ARE THERE
 OBSTACLES TO
 FUTURE USEFULNESS? IS IT
 QUALITY
 SOFTWARE? DEPENDENCY INVERSION REUSABLE EXEMPLARY REASONABLE TRANSPARENT UNIT TESTS TDD COVERAGE SRP TESTING INTEGRATION TESTS BDD MANUAL QA
49. IS IT QUALITY SOFTWARE? HOT NEW BUZZWORDS ▸ Functional Programming ▸ Type Systems ▸ Immutability ▸ Scalability
50. ACCURATE DOES IT WORK
 THE WAY WE THINK IT DOES? USEFUL
 DOES IT SOLVE
 A REAL PROBLEM
 EFFECTIVELY? SUSTAINABLE CAN WE KEEP
 BUILDING WITHOUT
 UNNECESSARY
 OBSTACLES? LISKOV SUBSTITUTION OPEN/CLOSED PRINCIPLE INTERFACE SEGREGATION DOES IT WORK
 FOR OUR USERS
 AS THEY EXPECT? CAN WE KEEP BUILDING OUR SYSTEM WITHOUT BREAKING OUR SYSTEM? ARE THERE
 OBSTACLES TO
 FUTURE USEFULNESS? IS IT
 QUALITY
 SOFTWARE? DEPENDENCY INVERSION REUSABLE EXEMPLARY REASONABLE TRANSPARENT UNIT TESTS TDD COVERAGE SCALABILITY TYPE SYSTEM FUNCTIONAL PROGRAMMING IMMUTABILITY SRP TESTING INTEGRATION TESTS BDD MANUAL QA
51. ACCURATE DOES IT WORK
 THE WAY WE THINK IT DOES? USEFUL
 DOES IT SOLVE
 A REAL PROBLEM
 EFFECTIVELY? SUSTAINABLE CAN WE KEEP
 BUILDING WITHOUT
 UNNECESSARY
 OBSTACLES? LISKOV SUBSTITUTION OPEN/CLOSED PRINCIPLE INTERFACE SEGREGATION DOES IT WORK
 FOR OUR USERS
 AS THEY EXPECT? CAN WE KEEP BUILDING OUR SYSTEM WITHOUT BREAKING OUR SYSTEM? ARE THERE
 OBSTACLES TO
 FUTURE USEFULNESS? IS IT
 QUALITY
 SOFTWARE? DEPENDENCY INVERSION REUSABLE EXEMPLARY REASONABLE TRANSPARENT UNIT TESTS TDD COVERAGE SCALABILITY TYPE SYSTEM FUNCTIONAL PROGRAMMING IMMUTABILITY SRP TESTING INTEGRATION TESTS BDD MANUAL QA
52. IS IT QUALITY SOFTWARE? COMPLEXITY METRICS ▸ Low Cyclomatic Complexity ▸ Low Connascence
53. ACCURATE DOES IT WORK
 THE WAY WE THINK IT DOES? USEFUL
 DOES IT SOLVE
 A REAL PROBLEM
 EFFECTIVELY? SUSTAINABLE CAN WE KEEP
 BUILDING WITHOUT
 UNNECESSARY
 OBSTACLES? LISKOV SUBSTITUTION OPEN/CLOSED PRINCIPLE INTERFACE SEGREGATION DOES IT WORK
 FOR OUR USERS
 AS THEY EXPECT? CAN WE KEEP BUILDING OUR SYSTEM WITHOUT BREAKING OUR SYSTEM? ARE THERE
 OBSTACLES TO
 FUTURE USEFULNESS? IS IT
 QUALITY
 SOFTWARE? DEPENDENCY INVERSION REUSABLE EXEMPLARY REASONABLE TRANSPARENT UNIT TESTS TDD COVERAGE SCALABILITY TYPE SYSTEM FUNCTIONAL PROGRAMMING IMMUTABILITY LOW CONNASCENCE LOW CYCLOMATIC COMPLEXITY SRP TESTING INTEGRATION TESTS BDD MANUAL QA
54. ACCURATE DOES IT WORK
 THE WAY WE THINK IT DOES? USEFUL
 DOES IT SOLVE
 A REAL PROBLEM
 EFFECTIVELY? SUSTAINABLE CAN WE KEEP
 BUILDING WITHOUT
 UNNECESSARY
 OBSTACLES? LISKOV SUBSTITUTION OPEN/CLOSED PRINCIPLE INTERFACE SEGREGATION DOES IT WORK
 FOR OUR USERS
 AS THEY EXPECT? CAN WE KEEP BUILDING OUR SYSTEM WITHOUT BREAKING OUR SYSTEM? ARE THERE
 OBSTACLES TO
 FUTURE USEFULNESS? IS IT
 QUALITY
 SOFTWARE? DEPENDENCY INVERSION REUSABLE EXEMPLARY REASONABLE TRANSPARENT UNIT TESTS TDD COVERAGE SCALABILITY TYPE SYSTEM FUNCTIONAL PROGRAMMING IMMUTABILITY LOW CONNASCENCE LOW CYCLOMATIC COMPLEXITY SRP TESTING INTEGRATION TESTS BDD MANUAL QA
55. IS IT QUALITY SOFTWARE? TEAM-ORIENTED PRACTICES ▸ Organization Conventions ▸ Style Guide ▸ Bus Factor (doing something about it) ▸ Code Review ▸ Pair/Mob Programming ▸ Internal Documentation (README and other helpful guides) ▸ Debugging Tools ▸ Mentorship
56. ACCURATE DOES IT WORK
 THE WAY WE THINK IT DOES? USEFUL
 DOES IT SOLVE
 A REAL PROBLEM
 EFFECTIVELY? SUSTAINABLE CAN WE KEEP
 BUILDING WITHOUT
 UNNECESSARY
 OBSTACLES? LISKOV SUBSTITUTION OPEN/CLOSED PRINCIPLE INTERFACE SEGREGATION DOES IT WORK
 FOR OUR USERS
 AS THEY EXPECT? CAN WE KEEP BUILDING OUR SYSTEM WITHOUT BREAKING OUR SYSTEM? ARE THERE
 OBSTACLES TO
 FUTURE USEFULNESS? IS IT
 QUALITY
 SOFTWARE? DEPENDENCY INVERSION REUSABLE EXEMPLARY REASONABLE TRANSPARENT UNIT TESTS TDD COVERAGE SCALABILITY TYPE SYSTEM FUNCTIONAL PROGRAMMING IMMUTABILITY LOW CONNASCENCE LOW CYCLOMATIC COMPLEXITY MENTORSHIP BUS FACTOR STYLE GUIDE ORGANIZATION CONVENTIONS INTERNAL DOCUMENTATION DEBUGGING TOOLS SRP TESTING PAIRING MOBBING CODE REVIEW INTEGRATION TESTS BDD MANUAL QA
57. ACCURATE DOES IT WORK
 THE WAY WE THINK IT DOES? USEFUL
 DOES IT SOLVE
 A REAL PROBLEM
 EFFECTIVELY? SUSTAINABLE CAN WE KEEP
 BUILDING WITHOUT
 UNNECESSARY
 OBSTACLES? LISKOV SUBSTITUTION OPEN/CLOSED PRINCIPLE INTERFACE SEGREGATION DOES IT WORK
 FOR OUR USERS
 AS THEY EXPECT? CAN WE KEEP BUILDING OUR SYSTEM WITHOUT BREAKING OUR SYSTEM? ARE THERE
 OBSTACLES TO
 FUTURE USEFULNESS? IS IT
 QUALITY
 SOFTWARE? DEPENDENCY INVERSION REUSABLE EXEMPLARY REASONABLE TRANSPARENT UNIT TESTS TDD COVERAGE SCALABILITY TYPE SYSTEM FUNCTIONAL PROGRAMMING IMMUTABILITY LOW CONNASCENCE LOW CYCLOMATIC COMPLEXITY MENTORSHIP BUS FACTOR STYLE GUIDE ORGANIZATION CONVENTIONS INTERNAL DOCUMENTATION DEBUGGING TOOLS SRP TESTING PAIRING MOBBING CODE REVIEW INTEGRATION TESTS BDD MANUAL QA
58. IS IT QUALITY SOFTWARE? MISCELLANEOUS ▸ Continuous Integration ▸ Frequent Releases ▸ Refactoring ▸ Conventional APIs
59. ACCURATE DOES IT WORK
 THE WAY WE THINK IT DOES? USEFUL
 DOES IT SOLVE
 A REAL PROBLEM
 EFFECTIVELY? SUSTAINABLE CAN WE KEEP
 BUILDING WITHOUT
 UNNECESSARY
 OBSTACLES? LISKOV SUBSTITUTION OPEN/CLOSED PRINCIPLE INTERFACE SEGREGATION DOES IT WORK
 FOR OUR USERS
 AS THEY EXPECT? CAN WE KEEP BUILDING OUR SYSTEM WITHOUT BREAKING OUR SYSTEM? ARE THERE
 OBSTACLES TO
 FUTURE USEFULNESS? IS IT
 QUALITY
 SOFTWARE? DEPENDENCY INVERSION REUSABLE EXEMPLARY REASONABLE TRANSPARENT UNIT TESTS TDD COVERAGE SCALABILITY TYPE SYSTEM FUNCTIONAL PROGRAMMING IMMUTABILITY LOW CONNASCENCE LOW CYCLOMATIC COMPLEXITY MENTORSHIP BUS FACTOR STYLE GUIDE ORGANIZATION CONVENTIONS INTERNAL DOCUMENTATION DEBUGGING TOOLS CONVENTIONAL
 APIS CONTINUOUS INTEGRATION REFACTORING SRP TESTING PAIRING MOBBING FREQUENT RELEASES CODE REVIEW INTEGRATION TESTS BDD MANUAL QA
60. SRP ACCURATE DOES IT WORK
 THE WAY WE THINK IT DOES? USEFUL
 DOES IT SOLVE
 A REAL PROBLEM
 EFFECTIVELY? SUSTAINABLE CAN WE KEEP
 BUILDING WITHOUT
 UNNECESSARY
 OBSTACLES? LISKOV SUBSTITUTION OPEN/CLOSED PRINCIPLE INTERFACE SEGREGATION DOES IT WORK
 FOR OUR USERS
 AS THEY EXPECT? CAN WE KEEP BUILDING OUR SYSTEM WITHOUT BREAKING OUR SYSTEM? ARE THERE
 OBSTACLES TO
 FUTURE USEFULNESS? IS IT
 QUALITY
 SOFTWARE? DEPENDENCY INVERSION REUSABLE EXEMPLARY REASONABLE TRANSPARENT TESTING UNIT TESTS TDD COVERAGE SCALABILITY TYPE SYSTEM FUNCTIONAL PROGRAMMING IMMUTABILITY LOW CONNASCENCE LOW CYCLOMATIC COMPLEXITY PAIRING MOBBING MENTORSHIP BUS FACTOR STYLE GUIDE ORGANIZATION CONVENTIONS INTERNAL DOCUMENTATION DEBUGGING TOOLS CONVENTIONAL
 APIS FREQUENT RELEASES CONTINUOUS INTEGRATION REFACTORING CODE REVIEW INTEGRATION TESTS BDD MANUAL QA
61. WHAT GOES IN THE RED AREA?
62. IS IT QUALITY SOFTWARE? USER-ORIENTED THINKING ▸ Focus on Delivering Value ▸ User Research and Collaboration ▸ Prioritization ▸ Discoverability ▸ Empathetic UI ▸ On Time ▸ Performance
63. CONVENTIONAL
 APIS SCALABILITY PRIORITIZATION USER RESEARCH/
 COLLABORATION PERFORMANCE EMPATHETIC UI DISCOVERABILITY ON TIME ACCURATE DOES IT WORK
 THE WAY WE THINK IT DOES? USEFUL
 DOES IT SOLVE
 A REAL PROBLEM
 EFFECTIVELY? SUSTAINABLE CAN WE KEEP
 BUILDING WITHOUT
 UNNECESSARY
 OBSTACLES? TYPE SYSTEM UNIT TESTS TDD CONTINUOUS INTEGRATION LISKOV SUBSTITUTION DEPENDENCY INVERSION LOW CONNASCENCE LOW CYCLOMATIC COMPLEXITY COVERAGE REFACTORING MENTORSHIP FUNCTIONAL PROGRAMMING IMMUTABILITY OPEN/CLOSED PRINCIPLE REUSABLE EXEMPLARY REASONABLE INTERFACE SEGREGATION BUS FACTOR STYLE GUIDE ORGANIZATION CONVENTIONS INTERNAL DOCUMENTATION DEBUGGING TOOLS DOES IT WORK
 FOR OUR USERS
 AS THEY EXPECT? CAN WE KEEP BUILDING OUR SYSTEM WITHOUT BREAKING OUR SYSTEM? ARE THERE
 OBSTACLES TO
 FUTURE USEFULNESS? IS IT
 QUALITY
 SOFTWARE? TRANSPARENT FOCUS ON DELIVERING VALUE SRP TESTING PAIRING MOBBING FREQUENT RELEASES CODE REVIEW INTEGRATION TESTS BDD MANUAL QA
64. CONVENTIONAL
 APIS SCALABILITY PRIORITIZATION USER RESEARCH/
 COLLABORATION PERFORMANCE EMPATHETIC UI DISCOVERABILITY ON TIME ACCURATE DOES IT WORK
 THE WAY WE THINK IT DOES? USEFUL
 DOES IT SOLVE
 A REAL PROBLEM
 EFFECTIVELY? SUSTAINABLE CAN WE KEEP
 BUILDING WITHOUT
 UNNECESSARY
 OBSTACLES? TYPE SYSTEM UNIT TESTS TDD CONTINUOUS INTEGRATION LISKOV SUBSTITUTION DEPENDENCY INVERSION LOW CONNASCENCE LOW CYCLOMATIC COMPLEXITY COVERAGE REFACTORING MENTORSHIP FUNCTIONAL PROGRAMMING IMMUTABILITY OPEN/CLOSED PRINCIPLE REUSABLE EXEMPLARY REASONABLE INTERFACE SEGREGATION BUS FACTOR STYLE GUIDE ORGANIZATION CONVENTIONS INTERNAL DOCUMENTATION DEBUGGING TOOLS DOES IT WORK
 FOR OUR USERS
 AS THEY EXPECT? CAN WE KEEP BUILDING OUR SYSTEM WITHOUT BREAKING OUR SYSTEM? ARE THERE
 OBSTACLES TO
 FUTURE USEFULNESS? IS IT
 QUALITY
 SOFTWARE? TRANSPARENT FOCUS ON DELIVERING VALUE SRP TESTING PAIRING MOBBING FREQUENT RELEASES CODE REVIEW INTEGRATION TESTS BDD MANUAL QA
65. IS IT QUALITY SOFTWARE? USER-ORIENTED THINKING (TECHNICAL PRODUCTS) ▸ Documentation ▸ Writing Client Code
66. CONVENTIONAL
 APIS SCALABILITY PRIORITIZATION USER RESEARCH/
 COLLABORATION DOCUMENTATION PERFORMANCE EMPATHETIC UI DISCOVERABILITY ON TIME ACCURATE DOES IT WORK
 THE WAY WE THINK IT DOES? USEFUL
 DOES IT SOLVE
 A REAL PROBLEM
 EFFECTIVELY? SUSTAINABLE CAN WE KEEP
 BUILDING WITHOUT
 UNNECESSARY
 OBSTACLES? TYPE SYSTEM UNIT TESTS TDD CONTINUOUS INTEGRATION LISKOV SUBSTITUTION DEPENDENCY INVERSION LOW CONNASCENCE LOW CYCLOMATIC COMPLEXITY COVERAGE REFACTORING MENTORSHIP FUNCTIONAL PROGRAMMING IMMUTABILITY OPEN/CLOSED PRINCIPLE REUSABLE EXEMPLARY REASONABLE INTERFACE SEGREGATION BUS FACTOR STYLE GUIDE ORGANIZATION CONVENTIONS INTERNAL DOCUMENTATION DEBUGGING TOOLS DOES IT WORK
 FOR OUR USERS
 AS THEY EXPECT? CAN WE KEEP BUILDING OUR SYSTEM WITHOUT BREAKING OUR SYSTEM? ARE THERE
 OBSTACLES TO
 FUTURE USEFULNESS? IS IT
 QUALITY
 SOFTWARE? TRANSPARENT FOCUS ON DELIVERING VALUE WRITING CLIENT CODE SRP TESTING PAIRING MOBBING FREQUENT RELEASES CODE REVIEW INTEGRATION TESTS BDD MANUAL QA
67. CONVENTIONAL
 APIS SCALABILITY PRIORITIZATION USER RESEARCH/
 COLLABORATION DOCUMENTATION PERFORMANCE EMPATHETIC UI DISCOVERABILITY ON TIME CODE REVIEW INTEGRATION TESTS BDD MANUAL QA ACCURATE DOES IT WORK
 THE WAY WE THINK IT DOES? USEFUL
 DOES IT SOLVE
 A REAL PROBLEM
 EFFECTIVELY? SUSTAINABLE CAN WE KEEP
 BUILDING WITHOUT
 UNNECESSARY
 OBSTACLES? TYPE SYSTEM UNIT TESTS TDD CONTINUOUS INTEGRATION LISKOV SUBSTITUTION DEPENDENCY INVERSION LOW CONNASCENCE LOW CYCLOMATIC COMPLEXITY COVERAGE REFACTORING MENTORSHIP FUNCTIONAL PROGRAMMING IMMUTABILITY OPEN/CLOSED PRINCIPLE REUSABLE EXEMPLARY REASONABLE INTERFACE SEGREGATION BUS FACTOR STYLE GUIDE ORGANIZATION CONVENTIONS INTERNAL DOCUMENTATION DEBUGGING TOOLS DOES IT WORK
 FOR OUR USERS
 AS THEY EXPECT? CAN WE KEEP BUILDING OUR SYSTEM WITHOUT BREAKING OUR SYSTEM? ARE THERE
 OBSTACLES TO
 FUTURE USEFULNESS? IS IT
 QUALITY
 SOFTWARE? TRANSPARENT FOCUS ON DELIVERING VALUE WRITING CLIENT CODE SRP TESTING PAIRING MOBBING FREQUENT RELEASES
68. IS IT QUALITY SOFTWARE? YOU DECIDE.
69. ACCURATE DOES IT WORK
 THE WAY WE THINK IT DOES? USEFUL
 DOES IT SOLVE
 A REAL PROBLEM
 EFFECTIVELY? SUSTAINABLE CAN WE KEEP
 BUILDING WITHOUT
 UNNECESSARY
 OBSTACLES? DOES IT WORK
 FOR OUR USERS
 AS THEY EXPECT? CAN WE KEEP BUILDING OUR SYSTEM WITHOUT BREAKING OUR SYSTEM? ARE THERE
 OBSTACLES TO
 FUTURE USEFULNESS? IS IT
 QUALITY
 SOFTWARE?
70. TRY THE EXERCISE WITH YOUR TEAM: AMCAPLAN.NINJA/RAILSCONF2017
71. PARTING THOUGHTS
72. 1. DIFFERENT PROJECTS REQUIRE DIFFERENT BALANCES OF FACTORS
73. (SEE KENT BECK’S 3X FRAMEWORK)
74. 2. I DON’T THINK IT’S BAD TO FOCUS ON GOOD CODE FIRST
75. REALIGNING OURSELVES WHY WORK ON “GOOD CODE” FIRST? ▸ More straightforward ▸ Business understanding is a long, fruitful journey ▸ It’s possible to get much better at “Good Code” very quickly ▸ Becomes automatic (minimal long-term cost) ▸ You can’t automate business understanding ▸ Implication ▸ Start out focused on “Good Code” ▸ Over time, focus more on business understanding
77. WHAT CAN I DO TO BUILD BUSINESS UNDERSTANDING?
78. REALIGNING OURSELVES WHAT CAN I DO TO BUILD BUSINESS UNDERSTANDING? ▸ Learn about: ▸ Your users ▸ Your industry ▸ The organization of your organization ▸ Business ideas ▸ Organizational and process theory ▸ Develop empathy skills
79. 3. OVER TIME, EMPATHY BECOMES EVER MORE IMPORTANT
80. WHAT CAN I DO TO BUILD EMPATHY SKILLS?
81. REALIGNING OURSELVES WHAT CAN I DO TO BUILD EMPATHY SKILLS? ▸ Read ▸ More on that next slide… ▸ Practice ▸ Cultivate curiosity about others, especially different others ▸ Listen to others ▸ See the humanity in others
83. DEVEMPATHYBOOK.CLUB
84. MAKE YOUR SOFTWARE VALUABLE. MAKE YOURSELF VALUABLE.
85. THANK YOU TIME! THANKS TO THESE PEOPLE WHO HAVE TAUGHT ME SO MUCH! ▸ Eugene Westbrook ▸ Robin Curry ▸ Brandon Westcott ▸ Andrew Holz ▸ Topper Bowers ▸ William Bajzek ▸ Yitz Schaffer
86. THANK YOU! ARIEL CAPLAN @AMCAPLAN AMCAPLAN.NINJA DEVEMPATHYBOOK.CLUB