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

What Comes After SOLID? Seeking Holistic Software Quality

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.

7b5a451ee25044b9c869e3e98b79425d?s=128

Ariel Caplan

April 25, 2017
Tweet

More Decks by Ariel Caplan

Other Decks in Technology

Transcript

  1. What Comes After SOLID? SEEKING HOLISTIC SOFTWARE QUALITY

  2. None
  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

  14. None
  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
  76. None
  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
  82. None
  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