Decision Logs

Create logs that hold the following information:

• Problem you are deciding on
• Involved people
• What did you choose? Why? Risks?
• What other things have you considered? Why didn’t you choose them?

Michael Nygard described his decision log structure in this blog post:

• Context: Describe the forces at play
• Decision: Your response to these forces
• Status: The decision status (e.g. “proposed”)
• Consequences: What happened afterwards?

How To Deal With Configuration

• Rely on useful default configuration which is stored inside the application:
  • e.g. using a log folder next to the application folder, using default schedule timers, etc.
  • Maybe it would make sense to create a default configuration file if it does not exist
• Allow external configuration via several sources. They can override each other:
  • Default values stored in the application
  • Configuration files
  • Command line arguments
  • Environment variables
• Throw a meaningful error on configuration problems
• Try to initialize resources if they are not found (e.g. create directories, create files, …)
• Create application arguments which allows a user to specify a configuration file in a specific place
• Some configuration (e.g. plugging an application into a logging service) should be disabled by default. A user can enable them if he wants to

Documentation

• https://arc42.org/documentation/
• Write documentation if
  • The thing you are documenting does not change often
  • Your documentation will be useful to a large group of people
• Four Kinds of Documentation
  • Tutorial: learning-oriented; a getting started guide
  • How-To Guide: goal-oriented; how to solve a specific problem
  • Explanation: understanding-oriented; provides background and context
  • Reference: information-oriented; describes inner processes

Chaos Engineering

Adding parameters for sleep timers and error rates to service requests can be an easy way to test how a specific service deals with issues in isolation.

Database Migrations

• Every developer has his/her own database. The build script offers ways to create and delete a database based on a configuration file (which is not put into version control). This configuration file contains the database name as well as a connection string
• Migration scripts (and test data) are put into version control

The Phoenix/Unicorn Project (Gene Kim)

Three Ways

• System Thinking
• Amplify Feedback Loops
• Culture Of Continual Experimentation And Learning

Five Types Of Work

• Business Projects
• Internal IT Projects
• Changes generated by the above
• Unplanned Work

Five Ideals

• Locality and Simplicity
• Focus, Flow, and Joy
• Improvement of Daily Work
• Psychological Safety
• Customer Focus

Accelerate (Nicole Forsgren PhD, Jez Humble and Gene Kim)

The book outlines 24 capabilities that drive improvements software delivery performance:

Continuous Delivery

• Version control
• Deployment automation
• Continuous integration
• Trunk-based development
• Test automation
• Test data management
• Shift left on security
• Continuous delivery

Architecture

• Loosely coupled architecture
• Empowered teams

Product and Process

• Customer feedback
• Value stream
• Working in small batches
• Team experimentation

Lean Management and Monitoring

• Change approval processes
• Monitoring
• Proactive notifications
• WIP limits
• Visualizing work

Cultural

• Westrum organizational culture
• Supporting learning
• Collaboration among teams
• Job satisfaction
• Transformational leadership

CAP Theorem

• Consistency
• Availability
• Partition tolerance

This theorem states that given a network partition (a split brain situation), a distributed system can either favor consistency or availability.

Example: Imagine that you are part of a fully remote wedding. Let’s imagine that you answer “the big question” with yes and let’s imagine that your phone/internet connection breaks before your significant other can answer the same question. What do you do? Do you say that you are married/not married (in which case you would favor availability) or do you say “I don’t know” (in which case you would favor consistency).

The PACELC theorem is an extension to the CAP theorem: In case of a network Partition, one has to choose between Availability and Consistency, Else, when a system does not have a partition, one has to choose between Latency and Consistency.

Martin Kleppmann posted an interesting article in which he explains that neither CAP nor PACELC are a good way to think about distributed systems.

Idealcast Podcast

Jeffrey Fredrick (Episode 14)

Employee satisfaction can indicate the performance of an organization. Ask:

• Are you happy?
• Are you able to do work that you are proud of?

Scott Havens (Episode 22 & 23)

• State management techniques used in functional programming can be used to scale large architecture such as Wal-Mart’s warehouse system
• Working with event streams as input and output makes a system decoupled, easier to test and more understandable
• A pure function can be replaced by a lookup table
• Scott mentions a story about how they recovered from a disaster involving the death of a Kafka cluster
• He also tells the story of how he replaced a synchronous call graph involving 23 procedures with asynchronous computation
• Category theory is not too important in your day-to-day use of functional patterns

Believes

• Working code is only the beginning
• Be prepared to throw away something you’ve done in order to do something different
• Always look for better ways of doing things
• “Good enough” isn’t good enough
• Code is a liability, not an asset
• Treat code like a garden. You are never “done”
• Prefer immutability
• Model actions as data
• Abstractions and data schemata are hard to get right. You will most likely change them in the future, so prepare yourself
• Technical excellence is not everything
• Backups don’t mean anything unless you have actually tried to restore data from them