Speaker: Jeff Wilson @mjeffw

For more, see table of contents

---

Quotes

• “Scrum is like your mother-in-law, it points out ALL your faults” – Ken Schwaber
• “Without requirements or design, programming is the art of adding bugs to an empty text file” – Louis Srygley
• Cartoon – “A good architect leaves a footprint” cartoon – gave up giving them names and just name layers after the architect.
• “Make it work; make it right; make it fast” – Kent Beck
• “If you are releasing software into production once every six months, you aren’t very good at it. If you can release software into production every 11.6 seconds like Amazon, you are bloody good at it” – Dave Farley

General

• In short term, those ignoring quality are faster. In long run, those focused on quality win
• Common problems:
  • we can’t demo anything until all the layers are addressed.
    • product owner should understand enough that can demo through a test
    • hexagonal architecture/prots-and-adapters – interchangeable requirements, can unit test or demo parts. Note all parts and draw a hexagon around them. Each layer has its own port and understands format. Adapter changes data to standard format.
  • must have a database to test business rules
    • can use in memory database or mock objects
  • testers have a different interpretation of requirements than developers
    • problem that put testing at end of process
    • better to have the tests being the requirements.
    • cannot release code until all requirements met and no failing test cases
    • BDD – gets business, developer and QA to collaborate. Gherkin acceptance tests (given/when/then)
  • we don’t understand the user stories until 3-4 days into the sprint
  • tech debt is slowing us down
  • can’t get through coding and testing in the same sprint
    • happens if stories too big
    • happens if silos
    • “waterfalling” as sprint – spend first two days for design, and…
  • can only test thru gui or api
    • test should be at lowest possible level of code
    • test UI/API separate from rest of system
    • inverted pyramid for # of tests is an anti-pattern
  • Low level quality
    • Designing to interfaces, not implementation
    • SOLID Principle
    • Robert Martin’s “Agile Software Development” book
    • Eric Gamma’s “Design Patterns” book
    • Robert Martin’s “Clean Code” book
    • Focus on maintainability because changing code all the time – readable, extensible, clear design well-defined interfaces, ease of build/reuse, sufficient documentations
    • Create domain objects (ex: social security number) rather than just using Strings

My take

Hexagonal architecture was new to me. I want to read more about it after the session. It’s always surprising what the “new” thing I learn in this type of talk is. I’ve read all the recommended books, but good recommendations.