• How Did Things Go Right? Learning More from Incidents at Netflix: Ryan Kitchens: https://www.infoq.com/news/2019/07/netflix-learn-from-incidents/. Good ideas. Often no root causes, there’s much to be learned from successful system interactions / migrations, keep an eye on how hard people have to work to keep the system up. Many pointers for further reading.


I’m learning more and more about Jenkins pipelines. Really cool. Today I created a job whose purpose in life is trigger other jobs with certain parameters set as part of an end-of-sprint delivery pipeline. The script {…} and build {…} directives were particularly handy. This trick is to keep everything as simple as you possibly can.

My current convention is to name jobs that should only be run by other jobs (not people) using lower-case-words-separated-by-hypens.

State of DevOps Report 2019

Metrics from previous years

  • Throughput
    • # daily deploys
    • Cycle time
  • Stability
    • Time to recover
    • # change related failures

Here’s a great capability summary diagram for SDO performance (software delivery and operational performance)

Psychological safety: can team members take calculated risks (What does this mean in practice? What are the limits to risk taking and how do people know they might be taking a larger leap than maybe they should at this point in time?), and can they be transparent with each other without worry of reprisal? [Culture]

Software delivery org’s effectiveness as a contributor to an organization’s overall goals / outcomes

Eg Organization metrics

  • Customer satisfaction
  • Profitability
  • Market share
  • Number of customers


There’s a big focus on individual, team productivity in this year’s report. Neat.

A definition of productivity that isn’t a count of lines of code or story points completed in a sprint. More it relates to a measure of our ability to dig in to complex tasks with minimal interruption. Hrm. Interesting. There are several contributing factors:

Productivity, burnout, and work juggling sidebar: as a general goal work to limit work in progress and context switching. Do this through process improvement and automation largely. Want … repeatable, reliable, fast, auditable systems changes always. <- These added capabilities that come from our tools dramatically increase our capacity to take on new work.

Internal search: how is the information from day to day conversations between team mates and diagrams, etc captured in a way that is easily retrievable in the future by maybe somebody who didn’t participate the original conversation? A knowledge base or radiator is hugely important. People join teams all the time. How long does it take them to get up to speed?

Cute. Technical debt as defined by Ward Cunningham is more nuanced that I guess I gave it credit for. Architecture, coding practice, complexity were in but not much else. There’s a nice list of stuff here though …

“Work Recovery” A thing I have struggled with in the past. You can create a context where people can leave work at work and achieve balance in life that contributes to overall wellbeing. Or not. Discourage this at your peril.

How new practices, ideas, tools spread through an org: community of practice, grassroots. (How teams transform.)


Privacy Law in Canada

Data privacy has always been and will always be important regardless of the industry I work in, but I can’t deny there’s a different feel to it working at an eHealth startup handling what I consider to be deeply personal, and private data about the people our tools are built to help.

So I have some learning to do about my role and responsibility to our users who can be doctors and patients. Notes to follow:


  • PIPEDA : Canadian Privacy Law
  • PHIPA : Ontario Privacy Law (Supercedes federal one.)




  • Property based testing : https://increment.com/testing/in-praise-of-property-based-testing/. An interesting idea. Generalize some of the tests we right to describe sets of input, not specific examples. (An specific example passing doesn’t necessarily tell you whether your behaviour is right. You may have missed a case that would produce an error.) Is this fuzz testing?



  • Bit of a memory refresh working with docker. Containers run as root. Mounting a dir into a tools container to generate output stored in the file system saves data as root. This was making Jenkins unhappy. 🙂
  • I create env variables in Jenkins to be able to use values across all stages (I can compute its value in a stage script {} block)
  • I can pass parameters around from the Jenkinsfiles. Sometimes pragmatism trumps security and other concerns.




  • Mounting an already primed Maven cache into a Maven build container makes a build much faster. Skips the dependency fetch step because they’re already there. It does require that you have a stable container host that builds run on … (Appropriate for ec2, ecs, but not Fargate. Spot or no probably doesn’t matter. The local .m2 cache can be rebuilt by the first build run on an instance.)


  • https://www.hostedgraphite.com/blog/incident-postmortem-template : Summary, what happened, what went right, what went wrong, how are we going to improve. I like this framework!