February 19, 2020

The Unicorn Project – Part 5

This week our book club talked about chapters 13-15.

Chapter 13

  • We liked the notion of a “whitespace change” deployment, where you make a change to something trivial like adding extra line breaks, and get everything completely out the door. This is a good approach to checking the deployment status, almost like a fire drill.
  • Regarding the database configuration string (is it in the config file, is it an environment variable), there are many ways to solve the problem, so how to you remember what you chose? Jameson said this is likely because they don’t consistently document things.
  • Following on to the config problem… the team identified it, resolved it, and found a way to ensure it doesn’t happen again.
  • Dennis said that production deployments should not be events. Most of us have worked in environments where deployments are events. We agreed that although frequent deployments are healthy, you still need to keep people (i.e., stakeholders) informed of what’s going on.
  • We debated what constitutes a “small change,” considering the change to encrypting social security numbers earlier in the book was a small change that ended up being a major fiasco.
  • The Unicorn team is dealing with constantly changing plans: This is the waterfall to Agile transition.
  • Geoff liked the notion of building the mindset that everyone did the best job they could given what they knew at the time. This assumes good intent.
  • We discussed some situations where waterfall would be preferable to Agile. It seems best suited for well understood landscapes where the requirements don’t change, where there is significant risk to be mitigated, and where the cost of change is high.
  • The idea of the store clerks looking up automotive parts in a physical book instead of a website was telling. Pay attention to the customer’s needs. Jameson reminded us that Bill and John did this with the business people in The Phoenix Project.
  • User personae are powerful tools for building stereotypes of your customers/users.
  • Experiments are an important vehicle for learning.
  • All product users and managers at Parts Unlimited have to go through in-store training to understand what the frontline folks are doing. Jameson shared that Pilot has the same program for all employees. He said this approach would be more effective if you waited for some time after you’ve acclimated to the role; doing it on week one means you have no context for how your job relates to the store’s work. Houston said Y-12 had a similar program.
  • Maxine gushes about how great the command-line is compared to a GUI. We disagree; each approach optimizes for different users. One is not superior to the other.
  • The parts stores don’t use the tablets because the user experience is horrible. This is where customer-centered design is critical.
  • Geoff pointed out another ham-fisted approach where Maxine recalls some piece of wisdom she learned about taking notes and how amazing she is that she does that. Jameson said at this point, Gene’s style of writing is distracting us from the story.
  • Regarding the software wanting employees to record the VIN (i.e., a long string of letters where the likelihood of mistyping is high)… It’s a badly designed system that depends on collecting good data that ultimately ends up leading to the collection of bad data. Jameson said this behavior happens when you make fields required without explaining why they’re required.

Chapter 14

  • Houston asked about the importance of naming your team. The group was split on how much that mattered, although we agreed that everyone on the team should give input. Also, the plural of Pokémon is Pokémon. 🙂
  • Geoff understands the approach that the Unicorn team cannot follow the process as is. However, the logic of “if rule bad, then break rule” is worse than “if rule bad, then change rule”.
  • Steve (CEO) is consistently on-message about the company’s goals and values, which is present even in the parts stores. Tell ’em, tell ’em, then tell ’em again.
  • Steve takes responsibility for the system downtime, which is closer to “extreme ownership.” You need more than just the top people: You need the entire chain.
  • We had some good discussion around the NOSQL move to “burn the ships.” It’s good that Maxine trusts the team and rides on goodwill. However, it seems the author is getting heavy-handed again about how relational databases are inferior. Geoff reminded the group that NOSQL is not “No SQL,” it’s “Not Only SQL.” Also, two weeks to re-engineer the backend is a bit preposterous in the real world. The book even calls out that such maneuvers are likely why the architectural review board (TEP-LARB) exists in the first place: to prevent decisions like these!
  • The example of Texas customers getting snow tire promotions is another instance of the scenario where you have data, but it may not be good data.
  • Decoupling services from data to make changes easier is one of the tenets of microservices.

Chapter 15

  • The team tests during regular work hours because the team is present and it’s a time of day when high traffic is more realistic.
  • Load testing is tricky because “load” can mean different things.
  • Geoff was surprised that the click-through rates on the promotion were so low. Apparently this is fairly common.
  • Sarah is marching around wondering why butts aren’t in seats and hands aren’t on keyboards. This is the classic micromanaging approach, which Geoff has experienced first-hand. Jameson reminded us that in The Phoenix Project, this is the point where Bill quit.
  • The team was able to make a last-minute change in an hour, which is a marker for how far they’ve come.
  • Don’t only focus on the problems. Recognize the things the team did right. Jameson said it’s like when you’re a teenager and your parents ask you to mow the lawn, take out the trash, and wash the dishes before the parents get back. They don’t see the mown lawn and empty sink: They see the full trash can.