This week our book club talked about chapters 7 through 9.
Chapter 7
- We liked the analogy of four strands of yarn being a simple system, yet once you braid those strands that system becomes “complected.”
- Being able to continually deliver working software is important to the business, and is also important to the people (e.g., morale, burnout).
- What used to be simple is now too complex. It requires planning and overhead to manage that complexity.
- “Tech debt is what you feel the next time you want to make a change.”
- Middle management is stuck in a one-way communication system (i.e., their bosses tell them what to make happen), even though they have the technical prowess to know that the train will derail. Jameson wondered what would have happened if those managers would have approached Sarah and gave her real-world examples in the language of the business about why this effort would fail.
- We want to avoid internal complexity. Houston posed that every system is complex to an outsider or newcomer.
- Geoff mentioned that Dr. Goldratt’s view of complexity is about how many degrees of freedom there are, not the dependency relationships per se.
- The Ideals
- Locality and simplicity
- Focus, flow, and joy
- Improvement of daily work
- Psychological safety
- Customer focus
- Jameson mentioned that customer focus is easily used by the business to stomp all over the other ideals.
- We agreed about the analogy of tech being a caste system (e.g., QA, dev, ops) and which is “better.”
Chapter 8
- We chuckled that the author couldn’t help mentioning how functional programming is superior at solving a race condition.
- Geoff was surprised that the developers weren’t even allowed to see the tests that would evaluate their work. Why play games?
- The Data Hub team is being blamed for outages, even though it’s not always their fault. Geoff experienced this in his last job where the end product was installed and maintained by people essentially outside the company. When the system wasn’t working, it was always the software’s fault, and never 1) someone not realizing a drive was full, or 2) a firewall rule had been reset by some other admin.
- Finger-pointing and blame-passing is rarely helpful.
- Houston mentioned the scenario where Maxine couldn’t access production logs — more hurry up and wait. The team can’t fix much less diagnose the problems.
- It’s waste for the developers to be working on builds and deployments instead of helping to create new features.
- Geoff thought the statements about the fall of Nokia being due to tech debt were a stretch. Some cursory Googling revealed that the root cause was internal political issues.
- We talked about Microsoft’s theme of if there’s a choice between adding features or increasing developer productivity, that the latter should be prioritized. I think if you’re as large as Microsoft, you get the luxury of making that choice. In general we agreed that if there’s a choice between new features and security, that security wins. Jameson said it’s all too easy to let “nice to have” things like security, documentation, and quality left on the cutting room floor to prioritize getting a feature out.
- For Phoenix, the least qualified people were working at the bottom. Where should senior devs go, then? Perhaps working on infrastructure and architecture (foundations), while the juniors and mids work on features. The seniors help people learn the system. They have proven themselves, so why not put them in a place to get more results?
- The industrial revolution required command-and-control style leadership where the mindless cogs were told what to do. In the information revolution that employs more knowledge workers, this doesn’t scale. It’s not possible for the person at the top to be capable of doing everything below them in the org.
- Regarding the Andon cord, Geoff thought it was a wonderful mindset to be thanked for finding an opportunity for improving daily work.
- Erik starts espousing the most important things, two of which Geoff took umbrage with…
- “pursuit of perfection” — this doesn’t sound healthy to seek an unachievable state
- not settling for the status quo — sometimes things are working and don’t need to change; don’t change for change’s sake
- One of the staff was working long days, was exhausted, and ended up typing a command into the wrong terminal window which lead to system outages. The response? Fire the employee. Yet another sign of a toxic culture.
- When advocating for change — implementing a new process, prioritizing tech debt over features — put your pitch in terms the business can understand (usually money or time).
- When in a leadership position, keep telling people the desired values and norms; don’t assume they know and understand them. Give examples of how leadership is modeling the values of the company. Have top management ask how leaders are specifically living those values (i.e., hold them accountable).
Chapter 9
- Imagine working in an environment where it took seven weeks to get to production. You need faster feedback! Geoff recounted a story from a previous company where it took 45 days to deploy an “emergency release”.
- Although it’s likely a plot device, we had a laugh about the developers not even having badge access to get into the QA building, as if they’d never have the need to talk to one another!
- QA is treated as an underclass: “…like Kurt had escaped some sort of ghetto.” This reinforces the caste system, where there is a bottom rung.
- Having test data that’s years old isn’t an issue for long-running projects. It becomes problematic if the most recent data is years old.
- Geoff thought this chapter had clumsy storytelling. Why is it relevant what Maxine had to eat? How is that relevant to the plot?
- In the end it’s about building trust between teams (e.g., dev and QA).