Quality + Speed

• Quality = of the code/solution
• Speed = of delivery

Quality vs Speed

too much of one == less of the other

find a balance between both

Buddha: truth lies in the middle way

Quality factors

• QA
• Acceptance Criteria
• Coding Style
• Pattern Guidelines
• Tests
• Documentation
• Code maintainability, simplicity, etc

Quality at jobs

at jobs we rock at Quality!!! :-)

Speed?

let's balance it with Quality

Speed enemies

• changes to PR
• conflicts of opinions

Why no Changes?

• Require time (Time vs Speed)

• produce Context Switching

Greatest Trick for speed

• Accept PR as is: do changes in another PR/ticket

• delay changes as much as posible (Divide and Conquer)

PR nature

• 1 requester (did the job)
• n reviewers (check code, QA)

if there's a problem between parts
it can become a 1:n problem ;-)

1:n problem

A conflict is solved faster when
reviewers (n) help the requester (1)

so: try to side with the requester (1) ;-)

PR psychology

• at the moment of PR, lots of work is already done
• We all love to see our code in production ... fast

Speed : the mindframe

reviewers should:

• have a helpful mind/approach

• always review with speed in mind

• devise tricks to speed up delivery

Type of Conflicts in PRs

• the Broken

• the Slow

• the Ugly

their importance is in that order

1. Broken e.g.

• Tests don't pass
• Acceptance Criteria not met
• Corner cases break

Broken nature

several degrees of Broken

some are stoppers, some not

Trick: the more 'not stoppers' => more speed

so: aim for no stoppers

Broken : not stopper, how to

Broken When? : corner cases of slow % usage

trick: relax Acceptance Criteria, talk to PO

Talk and Agree: deploy now, fix it later

2. Slow

prove your point: provide a benchmark

Trick: the right questions:

• Slow when?
• Should this code perform fast?

can the change be delayed, i.e. done in another ticket?

3. Ugly

Style guidelines help here

Talk, agree, delay changes when posible

Recommendation: try to avoid this argument ;-)

Main Proposal: in Conflicts

Always talk!!!

Proposal: conflict solved

comment it in PR so others know

YES: Delay changes to PR

• Deploy now, do fix/change in another PR

speed goes up +1

YES: when asking for changes

• offer your help/time
• Pair Programming is +1 :-)
• keep a helpful spirit (speed in mind)

YES: offer your time

• changes take time
  it feels lots nicer if you offer help

• Pair programming is Awesome :-)

YES: Namespaces save time

Tricks

• other teams code (namespaces) in jobs should get relaxed reviews
• main thing: jobs does not get broken

NO: long threads

• PRs focus gets lost, other reviewers are discouraged, etc...
• 1:n problem can become unmanageable
• remember the psychological part ;-)

Proposal: PR deadlines

• after 2 days a PR passes to QA
• 2 thumbs make it shorter than 2 days

Thanks