Model: Design Heuristics

Model: 3 kinds of heuristics

1. guide you closer to the solution

2. • design pattern

   • DDD pattern

   • structure for event source records

   • api design approach

3. guide you to other heuristics

4. determine our beliefs or values

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