Tuesday, December 10, 2013

Notes from Yow 2013 - December 9-10 2013

My notes from Yow Brisbane 2013

Jeff Patten

Scrum is based on rugby as mentioned in Takeuchi paper. 
To win the game takes more than just playing your position 
Finishing on time != winning 

Individuals and pegs prioritise safety over success

Scrum is an agile strategy not the rules of the game

Even if ur in time ur prob wrong anyway
Ur guesses about the future are prob wrong
Even if really good = right about 1/3 of the time
50-80% software fails to meet outcomes
It's only after delivery that we really understand value

"Design thinking" focuses whole teams in solving customer & user problems
Edmunds.com, IDEO Tim Brown Change by Design

Empathy, define, ideate, prototype, test

Whole team
Not always sequential

Lightweight personas
Sketching independently
Sketch studio
Lean us
Share results
Internal "trade show"

Stop worrying about velocity & start focusing on winning the game

Adding lean Startup to fix agile

Working software over comprehensive doco
Kent Beck:
Validated learning over working software (or comprehensive doco)

Explicit release, measure
Goals in Rpv: revenue per visit

Adding lean startup to fix design thinking

Spend time learning rather than arguing

Process is a fame strategy and au to win
Invest in understanding problem
Invest in validating outcomes
Maximise ? Minimise ?

Do it anyway they don't know what you're doing anyway
Just do it award

Charles Nutter @headius
Graal Interpreter/optimiser
Truffle AST

Michael Nygard

- make ops responsible for fast delivery
- make dev responsible for uptime

- share power
-- tools from ops side that let devs self-deploy
- Share knowledge 
-- Donella Meadows
--- "structure of info flows"
-- big visible displays - first way to introduce devops

Dev is prod
- Development infrastructure is mission critical

Statistical Sophistication
- Dan McKinley Homo Narrens

- hype cycle
- the paradox of automation

System comprehension tools?

Patrick Debois

Monitoring Stream Mapping
- reverse vsm
1. Seeing the devops system
2. Focus on flow
- remove friction
- Tech debt vs social debt
- codifying-devops-area-practices
Example practices
- infra as code
-- same tech versioning/testing
-- executable doco
-- common language
- reproducible envs 
- monitoring & metrics
-- enable devs to see prod usage/problems 
-- make it self-servicing 
-- devs can add metric to their code (statsd)
--- namespaces
-- make non-subjective decisions at start of project
- Devs wearing pagers
-- devs learn ops
-- ops learn dev
-- write better tests
- chaos monkey
- Zoome Atlassian 
-- visualise prod errors frequency per group 
-- enable extraction if context
- ChatOps
-- shared view
- Public post-mortems
-- chat makes it visible
- Game days
-- Find bottlenecks
- SadOps
- "You build it you run it"

Lyssa Adkins & Michael Spyd
Hiring Agile Coach
Silent release plan
Learning Objectives
Agile coach
Agile team facilitator
Be good at practitioner 
Be good at teaching or mentoring
Be good at coaching or facilitating
Only one of tech/busn/transformation

Coaching lessons 
Software ed
Email Lyssa

Sam Newman
Hexagonal Architecture - Alistair Cockburn
***Tip: Standardise gaps between services but be flexible about internals
Integration style evolution
- Data oriented -> procedure oriented -> doc oriented -> resource oriented
- further right = less coupled
Tip: Avoid RPC or shared serialisation
Have at most 3 ways of integrating - not 20
- "Web API Design" Apigee
-- cross some sections out
- "REST in Practice"
Tip: Avoid Distributed transactions/locking at all costs (CAP theorem)
- have to get *much* better at monitoring
- not badass if u use ssh multiplexer
- use synthetic transaction to test prod
- use correlation ids to help track down nasty bugs
- abstract underlying deployment
- Tip: have a single way of deploying to any env
- integration test
-- lots of services = while to run, false negatives, poor isolation, large scope to blame
-- keep to a minimum, how to test other service without intg test?
- A -> B(v2)
- diff apps should know what resources they need
- Upstream (A) writes test that tests dependencies
- downstream (B) runs those tests
- "Consumer driven contracts"
- growing pile of pending stuff
-- big release = higher risk
*** - Tip: don't let releases build up - release as soon as possible, preferably one at a time
- if u can't fix that before building new service
Architectural safety
- cascading failure
- Tip: use timeouts, circuit breakers & bulkheads to avoid cascading failures
-- fail fast, don't pass up the chain
-- read Release It
Tip: Service templates make it easy to do the right thing for each deployment platform - implement conventions yourself
Delay the need to intro breaking change
- consumer driven contracts 
- prefer ver # in URI
- coexist in same app as endpoints 

Other Talks
- "Rapid release"
- "Macro to micro"

Aaron Bedra
"Carded", "carding rings" = criminals test stolen credit cards against your website to then sell on black market
- abuse of your infra
HTTP method Verb distribution is important

Adrian Cockcroft
Anti-fragility = enough stress 
- Not to break or go flabby

Speed at scale = everything is broken
Karyon status page is machine and human readable e.g. Chaos monkey

Joel Pobar
32core, 144Gb, 3tb 
Entire code base for all teams
- Image macros
Perf lab