Published

Event-Driven Microservices, the Sense, the Non-sense and a Way Forward - Allard Buijze (https://www.youtube.com/watch?v=jrbWIS7BH70) Why microservices monolith that is well-structured, can scale as well What goes in one service? What goes in another? order customer product inventory Are you micro-pile-of-shit? - redeploy multiple services at one - strong dependencies on other service before you can do something “just go up, and then go right” anti-modularity forces !...

Unconditional Code - Michael Feathers (https://www.youtube.com/watch?v=AnZ0uTOerUI) Null Object Pattern something bad has happened, but we’ll act like it didn’t others: NaN, [], null, special case that error is part of our domain same in functional error has moved to the place where the error occurred when successful, do this -– Example count # groups of ‘1’ (blue here) “edgy code”, it has a lot of edge cases...

Exercise of chapter 1 https://github.com/TjenWellens/refactoring-the-book

In Book_ Toyota kata then mention the use of the Andon Cord. When they notice a quality problem, or a deviation off from the process standards, they pull it. This then halts the entire manufacturing line, and signals others to come. Then then swarm the problem in group, doing root cause analysis. They learn and improve the process, that is the goal. It’s also mentioned that this cord is pulled about 1000 times per shift....

For the context about what actually happened, see Case study_ extract a service from big-ball-of-mud Per client application (3 of them) Refactor to module Refactor to library Change to use our service (with fallback and throttle) We would collaborate here for step 3, maybe even be involved in the earlier steps so we get to know the code base. Our service . . Simplest service possible + client library Continue developing our service … … System is ‘done enough to use’ in [[story-extract-a-service-from-big-ball-of-mud....

Like mentioned in Can we use an Andon Cord in programming_ What type of learning could we do? Which problems can we swarm? How can we raise the bar to increase problems? We usually don’t consider the entire value stream (Model_ from idea till thank you) And we certainly don’t visualise it! In Toyota they play with buffer size (aka Kanban’s WIP limit) to create problems. Maybe if we broaden the scope beyond todo-doing-done, we can do the same....

For example, at a Toyota assembly plant, I once was told that the normal number of andon pulls is typically around 1,000 per shift. Each pull is an operator calling for assistance from their team leader because the operator is experiencing a problem; a cross-threaded bolt here, a task that took a little too long there. Naturally, the number of andon pulls per shift varies, and I once heard of it dropping to only 700 pulls/shift....

The purpose of kanban is to eliminate the kanban. (src: Book_ Toyota kata)

Before: There are 3 services, part of a product. The users of the system, need to interact with all 3 services. There is no unified way / place for interacting with all 3. Each system is owned by a separate team. Both the users and the services are internal to the company. Assignment: Create a single point for the user to interact with the system (instead of 3) Rethink the way users interact with the product, so it closer matches the product vision....

postmortem has 3 important jobs explain what happened apologize commit to improvement anomalies and root cause we look for causes, and any anomaly either get's labeled as a root cause or a contributing factor many times these anomalies are present during "ordinary operations, too. We give them more weight that they deserve anomalies are present all the time learn from “near misses” eg. type an incorrect command, but catch it before executing...