Model: Design Heuristics ./resources/session-heuristic-hunting-techniques-rebecca-wirfs.resources/unknown_filename.png

./resources/session-heuristic-hunting-techniques-rebecca-wirfs.resources/unknown_filename.1.png

./resources/session-heuristic-hunting-techniques-rebecca-wirfs.resources/unknown_filename.2.png

Model: 3 kinds of heuristics

  1. guide you closer to the solution
    • design pattern
    • DDD pattern
    • structure for event source records
    • api design approach
  2. guide you to other heuristics
  3. determine our beliefs or values

./resources/session-heuristic-hunting-techniques-rebecca-wirfs.resources/unknown_filename.3.png

eg. DDD guiding heuristics

  • compose based on subdomains
  • ubiquitous language
  • domain events

Competing Heuristics

Do you do TDD? Kind of why?

  • depends on complexity of the problem

Heuristic: Don’t checkin (a large chunk of) code without tests ; before or after does not matter

Guiding Heuristic:

  1. spike: play around without tests
  2. TDD: then do it well with

composing the 2

being able to express those heuristics practice our ‘heuristic explaining approaches’

dogmatic as a learning tool

  • Do TDD very dogmatic for 6 months, then you know when to apply it

Naming heuristics (like patterns have a name)

Value Heuristic: Consistency over Cleverness

  • consistency over clever new language feature
  • so where are we going to use lambdas?

Heuristic: Anti Jack Bauer

  • “We have to do this, we don’t have another choice”
  • There is always another option
  • It’s never only binary
  • constantly expand where you are looking

Heuristic: Airline Heuristic

constraint vs specification maybe the name does not work for me

“what would you not do?”

  • hack the production code
    • you could create a new branch and test it out

Heuristic: No-code

  • can we do this without code?

Heuristic: Do we have to automate this?

when you disagree: competing heuristics

Which design should we do? You take mine, I’ll take yours

Heuristic - Pattern - Principle “all patterns are heuristics”

  • never guaranteed

principles, value, belief

  • principle = firmly held belief, if violated, you’d feel bad

solid principles are not principles

all heuristics, even principles,

SOLID = rigid

  • acronym
    • not open for extension itself
    • Micheal Feathers
  • single responsibility == cohesion but with an S instead of a C

Book: Dilly Van Ceun “even scientific method proven things are heuristics”

http://www.physicsofsoftware.com/papers.html

Is conway’s law a law?

  • it was never accepted, so no
  • it was a theory

beliefs or values are context dependent

  • testing
  • consistency
  • maintainable code

The Application of heuristics needs to be context dependent

  • which heuristic
  • influencing

Frugal Heuristics

  • good enough, that does not take too much
  • eg. Junior must draw all dependencies between objects
    • if there is a circle, come talk to a senior
  • Heuristic: recognition == most recently used
    • pattern recognition

Resources? Jaw Rosa tried to start a wiki ( http://principles-wiki.net )

  • collaboration heuristics

Rebecca is looking for design heuristics Literature about heuristics Literature about design heuristics aka Design Patterns Book: Philosophy of software design

context: time & lifecycle of a project

Heuristic: Kill your darlings

  • for music

“We’re so worried that we would have to do things twice”

  • “Design is a bet on the future” – Weinberg
  • rework is feature, not a bug
    • rework is a learning process

Heuristic: Let’s get started

Heuristic: If it is not broken, don’t fix it