Activity for apoena.dev

The commit that took 611 seconds

# The commit that took 611 seconds > A one-line note edit froze the typewriter I'm building for ten minutes. Here are the two hunts it took — one for the commit, one for the push — before the device published my whole second brain end-to-end for the first time. I'm building a small device called **Typoena**: an e-ink panel, a mechanical keyboard, an ESP32-S3, one purpose. You write Markdown, you press a key, it publishes to GitHub. I already made peace with that keystroke taking 5–10 seconds — the story of _why that's fine_ is a separate note about durability before delivery. This is the story of the day it didn't take 10 seconds. It took forever. ## The freeze That earlier note rests on one assumption: the local commit lands in about 0.2 seconds, and everything after is just transport. True on my toy test repo. Then I pointed the device at the repo it's actually _for_ — these notes, a real clone of 1179 files and a 263 MB pack, ~150 MB of it images. I edited one line. I pressed publish. The device froze. Ten minutes later it was still frozen. I power-cycled it — and it re-entered the exact same freeze. Not once did a single sync ever complete. Zero. The 0.2-second commit I'd built a whole argument on top of was, on the real repo, an infinite loop wearing a progress bar. ## The hunt The temptation with a frozen device is to guess: the card is slow, the repo is too big, the network stalled. Instead I did the boring thing — drew the system and turned every guess into a hypothesis I could kill with a measurement. Two benches on the device itself: one for raw filesystem timings, one for the git primitives running against the real clone. Four confident theories died to those benches: | Theory | Measured | Verdict | | --- | --- | --- | | The SD card is just slow | full loose-object write composite: **86 ms**, 8× faster than git's number | wrong | | The card is nearly full, so allocation crawls | **77 ms** — unchanged on a full card | wrong | | Strict OID validation adds a commit premium | 1.80 s vs 1.93 s with it off — no premium | wrong | | A window cache over the pack reads will help | **0 hits in 313 reads** — every read was unique | wrong | That fourth one stings the most: it was the only fix I _built_ before I'd proven the cause. Four instrumented runs, zero cache hits, deleted the same day. Everything else I refuted before writing a line of it. The real culprit was hiding in libgit2's index code. `git_index_write` unconditionally runs `truncate_racily_clean`: it re-hashes every file whose modification time isn't _strictly_ older than the index's own timestamp, to catch edits made within the filesystem's timing resolution. On a normal disk that's a handful of files. But FAT — what the SD card uses — records modification times with **2-second granularity**. On a fresh clone, every one of the 1179 files looks "possibly just edited." So writing the index to record my one-line change re-hashed the entire tree — ~170 MB, most of it images I never touched — bit by bit over a 10 MHz SPI bus. Measured across three consecutive writes: **611 s, then 12.8 s, then 360 ms**. The number only decays because each write nudges the index timestamp forward, shrinking the "suspicious" set. And that's the answer to why a reset never helped: a crash mid-write means the timestamp never advances, so the next boot re-hashes all 170 MB again. It re-enters the freeze forever by design. Drawn out, the whole publish looked like this — the local commit never handing off to the push: ``` publish (before) │ ├─ local commit │ · stage all 1179 files, then write the git index │ · FAT's 2 s timestamps make the whole tree look │ "maybe edited", so the write re-hashes ~170 MB │ (150 MB of it images) over a 10 MHz SPI bus │ · result: 611 s, and a reset re-enters the freeze │ └─ push (never reached) ``` ## The fix :git-commit: The insight is that the index is the problem, so the fix is to never touch it. Git already stores every past version of the tree as content-addressed objects. A commit doesn't _need_ the index; it needs a tree object. So instead of restaging the world, I rebuild only the path that changed: - Start from the parent commit's tree — already on disk, nothing to hash. - For the one edited file, hash its new contents into a blob. - Walk _up_ from that file to the root, writing a new tree object at each level and carrying every sibling entry forward **by its existing object ID**. For a note three folders deep, that's reading and writing about three tree objects. The other 1178 files, including all 150 MB of images, are referenced by ID and never opened. The cost depends on the _depth_ of the edited path, not the size of the repo — so it can't regress as the notes tree grows. That property is the whole point; every index-shaped alternative just moves the same wall somewhere else. The same publish, redrawn: ``` publish (after) │ ├─ local commit │ · for the one edited path only: │ read the file into a blob, │ rebuild its ~3 ancestor trees │ · write the commit object │ · no index, no full-tree walk, no re-hash │ · the other 1178 files carried by object ID │ · result: a few seconds; cost = path depth, │ not repo size │ └─ push ~6 s on the wire (its own fight — below) ``` A companion setting made the far-away seeks into the 263 MB pack cheap too — FAT's fast-seek mode with a small cluster-map buffer took a representative seek from **198.7 ms to 20.4 ms**. On device, against the real clone: the commit half now runs in **a few seconds** (the splice at 5.0 s, the commit object at 1.2 s) with the screen updating the whole time — where before it was infinite. For the first time ever, the device commits its own repo. Committing, it turned out, was half the war. ## The push fought back With the commit fixed, I ran the first full publish. The commit landed, the push went silent for 66 seconds — and then the firmware aborted the moment I typed a key. The abort wasn't in the push path at all: the editor allocated a fresh framebuffer on every repaint, and the push had eaten the heap out from under it. That exposed an ugly asymmetry. When a C `malloc` fails inside libgit2, it comes back as an error I can put on screen; when a Rust `Vec` allocation fails, the whole process aborts. The editor now draws into two frames allocated at boot, so a heap-starved push can fail without taking the keyboard down with it. Then the silence itself. My progress callbacks logged nothing for those 65 seconds — partly because libgit2 reports a total of zero while inserting objects, so a count-gated log never fires, but mostly because the longest phase has no callbacks at all: before sending a single byte, `mark_edges_uninteresting` reads the remote tip's entire ~1200-object tree to work out the boundary of what to send. A time-gated heartbeat finally named where the memory went: the mmap emulation. FAT has no mmap, so every "map" is a real allocation — and at the worst moment it held 7.15 MB of the 8 MB pool, leaving 472 bytes free. The window limit I had configured worked exactly as asked and didn't matter, because whole-file maps of the pack indexes (~3.4 MB) live outside that budget entirely. You have to budget the whole emulation, not the one knob the library exposes. With memory tamed, the push died one last way: an SSL error at the first byte of upload. That boundary walk took 32 seconds, GitHub closes an idle connection at around 30, and libgit2 treats the dead socket as fatal. The fix wasn't network code — it was `git repack -ad` on the source clone before loading the card. The same repository as one pack instead of five turned the 32-second walk into 3.5 seconds (two 64 KB windows read instead of 95), comfortably inside the keep-alive window. The push went through. On 2026-07-13, the device published to the real repo end-to-end for the first time: **24.1 seconds** from keypress to the on-screen confirmation. The split: 3.7 s of Wi-Fi bring-up, 0.6 s of clock and TLS, 19.8 s of publish (splice 5.0 s, commit object 1.2 s, push ≈ 6.1 s, the rest in opening the repo and updating refs). The whole thing was always about one number: seconds from keypress to the on-screen "published" confirmation, on the real repo. The freeze made that number infinite; the target was to get it under about ten. ``` seconds from keypress to "published" · lower is better before ████████████████████████████████████████ 611 s, then never finished now ██ 24.1 s, measured end-to-end target █ ≤ 10 s ``` The target isn't met yet, but the failure changed category: from "bricks the device, forever" to a finite number to shave. The next slices are known — the splice's 5 seconds and the ~7 seconds of repo-open and negotiation overhead. ## What it taught me - **Bench the real thing.** The toy repo understated everything by two orders of magnitude. "Works on the toy" hid a total brick. A simplistic model of the problem is worse than none. - **Refute before you build.** Four theories, killed by measurement, for free. The one thing I built on an unproven hunch was the only wasted work. - **FAT breaks POSIX assumptions.** 2-second timestamps, no inodes, no mmap, seeks that walk a cluster chain. Any library that assumes a real filesystem needs its cost model re-checked before you trust it here. - **Prefer a fix that's flat in N.** The one that can't come back as the repo grows is the one worth shipping. - **The UI must not share a fate with the plumbing.** A failed allocation inside libgit2 degrades to an error message; a failed one in the editor's draw loop took down the firmware. Anything that must survive a memory squeeze allocates at boot, not per frame. - **Put telemetry on the right axis.** Count-gated progress logging produced zero lines in 65 seconds, because the library reports zero totals while inserting and its longest phase fires no callbacks at all. Gating on time instead named the culprit in a single run. - **Pack layout is a performance setting.** The same clone as five packs or one is the difference between a 32-second boundary walk and a 3.5-second one. Repacking before loading the card is preparation, not optimization. This was a small kaizen, run properly — twice, in the end: one loop for the commit, a second for the push. Understand the potential, analyse the current method, generate and choose an idea, plan the test, implement, evaluate. The kind of problem-solving loop I keep coming back to — go and see before you conclude. And it closes the loop on the durability-before-delivery note: that argument assumed the local commit was fast and safe. This is the work that made the assumption true on the repo that actually matters. --- ## References - Durability before delivery — the companion note on why Typoena's slow keystroke doesn't feel slow. - Debugger avec méthode — draw the system, test one hypothesis at a time. - Make microcommits — one thing at a time, all the way down to how a commit is built. - FatFS `f_lseek` docs — the cluster-chain walk and the fast-seek mechanism: <http://elm-chan.org/fsw/ff/doc/lseek.html>

Gemba Kaizen

# Gemba Kaizen ## Masaaki Imai | 今井 正明 - 1997 ## De quoi traite le livre Le livre traite de la gestion de l'amélioration continue dans une entreprise. Lorsque tu as des flux désynchronisés, tu commences à t'adapter au flux le plus lent. Tu ne peux pas te tromper de problème à vouloir synchroniser les flux et à vouloir diviser par 2 le lead time. Le gemba n'est pas une visite du président, mais un élément essentiel du management pour être le plus pertinent possible dans les solutions à apporter sur le terrain. Ça demande de mettre des ressources en support pour tenir la synchronisation. ## An introduction to Kaizen ### Major kaizen principles `Process over result` : le but est d'orienter la réflexion sur les personnes et leurs apprentissages plus que sur le résultat. `PDCA/SDCA` : suivre avant tout la qualité. Le fait de ne jamais laisser des défauts à son client, même internes, est une priorité. Cela passe par voir de la donnée et l'analyser. Sans donnée, on est surtout que sur du ressenti qu'on aimerait justement affirmer ou infirmer. Laisser à tout le monde des suggestions de sujets quels qu'ils soient doit faire partie des rôles du top management. Le but principal est de développer l'état d'esprit kaizen et l'autodiscipline des employés. Le management en tête pour montrer l'exemple. ### Small group activities Une stratégie kaizen inclut le fait de faire des activités de petits groupes. Qu'elles soient informelles, inter-entreprises. La plus populaire des activités est le cercle de la qualité. ## Gemba Kaizen Gemba : là où les choses se passent. Là où l'ajout de valeur se fait. QCD (Quality → Cost → Delivery) : une lentille intéressante pour prioriser des sujets. > [!NOTE] > Ce que je ne souhaite pas par dessus tout c'est de perdre mon habilité à comprendre le lieu de travail. La peur de se confronter au vrai. Low-cost improvement. C'est la priorité d'un Kaizen officer. > If the client is king, then the gemba is Buddha. ### The golden rules of _Gemba_ management 1. When a problem _(abnormality)_ arisess, go to the gemba first, 2. check the gembutsu: what are the relevant objects to see? 3. take temporary countermeasures on the spot (Comment faire en sorte que ces contre-mesures sont effectivement temporaires ?) 4. find the deep causes - (les causes racines n'existent pas), 5. standardize to prevent recurrence. (Que veut dire standardiser ? Combien de gestes doit-on standardiser dans l'informatique ?) #### Go to the gemba _first_ Les personnes qui s'occupent de la finance _(que ce soit interne ou chez le client)_ auront du mal à allouer des ressources à tout ce qui est gemba / kaizen car il n'y a pas de résultat immédiat. Le gemba et le kaizen sont des activités censées apporter sur le long terme. Maintenir, améliorer pour mieux produire doivent être sacralisés pour l'ensemble de l'équipe. > [!NOTE] > En tant que prestataire, nous sommes limités de cette sacralisation mais nous pouvons faire plus que nous le pensons. Dans l'exemple ci-dessous, l'auteur nous rappelle un 5ème M pour **M**easurement : > The temperature of the rotemburo _(source thermale extérieure)_ was too hot, the engineers didn't spot it because they don't go to the gemba. They monitor a secondary information. Les indicateurs sont bons mais les regarder exclusivement nous empêche de voir la réalité du terrain. > When you see data, doubt them! When you see measurements, doubt them! > > Dr. Kaoru Ishikawa Aller sur le terrain est la première action à faire pour améliorer les relations dans une hierarchie. Gagner de la confiance entre les strats et gagner en humilité. Les managers qui _se plaignent_ est un indicateur qu'ils ne vont pas assez souvent sur le terrain. #### Check the gembutsu "Gembutsu" : ce qui est tangible et physique. C'est en partant du concret que l'on commence à se poser les questions de pourquoi le défaut est apparu. > Using a commonsense, low-cost approach, managers should be able to identify the root cause of a problem without applying sophisticated technology. Que veut dire "commonsense" ? Est-ce que ça ne va pas à l'encontre de la compréhension de l'erreur humaine ? Est-ce que le sens commun suffit la plupart du temps ? Est-ce qu'on n'oublie pas les effets secondaires qui pourraient en découler ? Faut-il tenter ou faut-il se limiter de peur de provoquer plus de mal que de bien ? #### Take temporary countermeasures on the spot > Sometimes kicking the machine will do the job! Les contre-mesures temporaires adressent un symptôme et non une cause racine. Voilà pourquoi il est important de se poser plusieurs fois la question de pourquoi. > [!NOTE] > Ma première résolution de problème chez BAM avec Guillaume portait sur un mauvais contrat d'interface entre le frontend et le backend. J'avais raté ma journée car j'ai dû retravailler la manière de récupérer les données. Je me suis d'abord dit que je n'avais pas vérifié, double-vérifié et triple-vérifié ce que j'étais en train de développer, je me suis dit alors "il faut que je fasse plus attention". J'avais inconsciemment enlever l'hypothèse qu'une contre-mesure pouvait être faite en amont, je savais que tout le monde était sous l'eau surtout le développeur backend (CTO et développeur fullstack qui apprenait en même temps React Native). Elle demandait plus de courage car elle demandait de discuter et de négocier. Elle demandait plus de compréhension du système : "aller voir la personne qui crée le contrat d'interface de l'API". Ce qui fait aller plus loin que la contre-mesure temporaire sont : l'autodiscipline et la détermination de l'amélioration continue. #### Find the root cause > With a good look at the gembutsu at the side and determination to identify root cause, many problems can be solved on the spot and in real time. Other problems require substantial preparation and planning to solve. Que se passe-t-il lorsqu'il y a trop de problèmes rencontrés ? Ou que la solution demande trop d'effort ? > The opportunities for making a change abount in the gemba, and one of the most popular axioms of gemba kaizen is, "Do it now. Do it right away!" Le temps requis que propose l'auteur ici se situe entre quelques heures à quelques jours. Est-ce trop chez BAM ? Oui, pour l'instant chez nous. #### Standardize to prevent recurrence > Manager's task at the gemba is to realize QCD. Ok, il est sans équivoque : il sait qu'il y a des problèmes tous les jours, des objectifs atteints toutes les semaines, des personnes en retard tous les matins. Pourtant il propose l'idée suivante : tous les problèmes doivent être réglés. "Whenever a given problem arises, management must solve it and make sure that it will not recur for the same reason. Once solved, the new procedure needs to be standardized and the SDCA cycle invoked. **Otherwise, people are always busy firefighting**". > **Standard**: the best way to do a job. > > Managers who do not take the initiative to standardize the work procedure forfeit their job of managing the _gemba_. ## Quality, Cost and Delivery at the _Gemba_ Le coût ne peut être vu comme la seule indication d'une bonne affaire (exemple : délocaliser pour moins cher rend le coût de production d'une unité moins cher mais en impactant la qualité et/ou temps de livraison). > You get what you pay for. C'est pour cela qu'il propose le coût final comme la réflexion des interactions entre qualité, coût et délai. Un diagrame de qualité/assurance montre un flux d'activités qui s'assurent de la qualité à chaque étape en ajoutant une dimension de qui produit lors de l'étape : `steps\department: related standards`. Le diagramme montre aussi les activités interéquipes (comme des conférences, des jalons, des réunions). La création d'un objet commence par un papier et un stylo. Les bugs peuvent être corrigés en un coup de stylo sans aucun coût. Les activités de cercle de qualité sont à encourager dans l'ensemble des équipes que l'on peut avoir chez BAM. Ce point d'équipe ne doit pas être le seul moment qualité, mais _une_ opportunités en plus. Dans ses différents graphs (comme une BDC), il annote le moment où l'on a fait une nouvelle action : uniformisation des standards, introduction du juste-à-temps, création d'un guide manuel. Cela permet de se réferrer toujours aux mêmes indicateurs. La qualité commence lorsque tout le monde sse met d'accord pour ne pas accepter de pièces défectueuses. La notion de Jidoka : "don't accept defects, don't make defects, don't pass defects.". Le lean n'est pas la réduction des coûts mais sa gestion. Prendre des raccourcis comme licencier des personnes, prendre au moins cher engendrent inéluctablement une détérioration de la qualité. Le management du coût se traduit par : 1. La maximisation de la marge entre les coûts et le revenu, 2. la diminution des couts sur le gemba : muda, 3. la planification de l'investissement par le top management. ### Raccourcir la chaîne de production Lorsque l'on ajoute des process ou des contrôles de qualité dans notre CI, nous rallongeons la chaîne de production. Limiter le nombre d'étapes (_cad_ lignes de commande) est un moyen de gagner en qualité en réduisant la chance de nouvelles erreurs, de maintenance et en lead time. ### Améliorer la qualité et réduire les coûts Le thème du livre est de nous assurer que l'amélioration de la qualité et la réduction des coûts sont compatibles et réalisable en même temps. > La qualité ne coûte pas plus d'argent. Si le QCD pouvait être vu comme une relation d'ordre, c'est bien la volonté de faire mieux dans les 3 métriques _en même temps_ qui est recherché. L'amélioration se fait par "la qualité avant tout !". ## Standards Un standard est une méthode à suivre, à maintenir et à améliorer. Si en Occident, on pense que le standard est un moyen de contrôler les personnes, au Japon, il est vu comme un moyen de contrôler les process et nons les personnes. Il faut voir le standard comme la manière la meilleure, la plus sûre et la plus facile de réaliser un travail. Il peut y avoir des réticences à suivre un standard → ces réticences doivent pouvoir être comprises. Le rôle du management est de maintenir et améliorer les standards mis en place. > Un jeune parachutiste n'aurait besoin de plier qu'une seule fois son parachute pour la première fois pour dormir paisiblement. Si un standard existe, c'est un moyen d'apprendre des plus expérimentés et de nos erreurs. Chaque tragédie a permis de poser la question : "quelle mauvaise manipulation dans notre manière de plier le parachute à amener à cette tragédie ?". La maintenance fait partie de la vie de tous les jours pour le management, elle doit même être la majorité de son activité. Seulement une fois que la maintenance est stabilisée que l'on peut viser l'amélioration. > Where there is no standard, there can be no improvement. Un manageur faisait 6 A3 par mois. Un A3 n'est pas un exercice de remplissage de formulaire. ## Chapitre 5 - The 5S: the five steps of workplace organization > Kaizen: the first step is 5S 3 activités : 1. Standardisation, 2. 5S, 3. élimination des gaspillages. ### Seiri Trier : faire la distinction entre ce qui est utile de ce qui est inutile. #### Les étiquettes rouges Placer des étiquettes rouges partout où l'on pense qu'un outil est inutile. Si l'outil n'est pas utilisé dans les 30 jours. Le retirer. Lorsqu'il y a une étiquette rouge, il n'y a pas de présomption d'innocence mais une présomption de culpabilité : c'est à la personne qui pense que l'outil est utile de démontrer son utilité. ### Seiton > This is the best way to show the harder they work, the more money the company lose. > > Taichii Ohno _en demandant de remettre le trop-plein à la station de travail qui l'avait produit_ Suffit-il d'être sérieux pour réussir ? ### Seiso Nettoyer permet de vérifier le bon fonctionnement. Voir plus rapidement un disfonctionnement lorsque l'endroit est nettoyer et où les problèmes se voient en un coup d'œil. ### Seiketsu La systématisation des gestes tous les jours par tout le monde. ### Shitsuke L'autodiscipline. Écrire puis suivre les standards définis qui sont eux-même pertinents pour de bonnes conditions de travail. Les standards doivent permettre d'évaluer le progrès de chaque étape. _Je ne sais pas trop ce qu'il entend par ça, en tout cas, je n'ai pas d'exemple._ Le 5S doit faire partie d'un système qui s'assure de la continuité des pratiques. ### Introduire le 5S Par où commencer ? 1. Préparer mentalement les employés avec un temps pour discuter de la philosophie et des bien faits du 5S, 1. Créer un espace propre, agréable et sur, 2. revitaliser le gemba et améliorer la motivation et le moral des employés, 3. éliminer les différents types de muda en diminuant le temps de recherche d'outils. Rendant le travail plus facile. ## Chapitre 6 - Muda > May I ask you to do at least one hour's worth of work every day? ### Muda of overproduction The urge of being on the safe side. "I've done my part. This is a false sense of security and cover up all sort of problems." Sans regarder la quantité dont a besoin la prochaine équipe. Dans le juste-à-temps, être en avance est pire qu'être en retard. > DO NOT PRODUCE AHEAD OF TIME. > /// Nempashi's video Trop produire est le **pire** des gaspillages : ajout de stock, ajout de main d'œuvre, ajout d'outillage et de machines. _Et donc pire que des défauts ?_ ### Muda of inventory Les produits non finis, non transmis à l'utilisateur final est de la non valeur. Si la surproduction est un crime, l'inventaire doit être vu comme l'ennemi à détruire. Plus l'inventaire est important moins les personnes ne s'intéressent aux problèmes. ### Muda of defects Les défauts interrompent la production and demandent de retravail. ### Muda of motion Les déplacements en informatique peuvent être vu dans le déplacement non nécessaire de l'information, de la duplication. On peut voir des déplacements dans la recherche de plusieurs applications sur son ordinateur. ### Muda of processing Faire passer une pièce par des étapes qui ne sont pas utiles, lentes ou désynchronisés. ### Muda of waiting La stagnation. Aaah, la stagnation. Facile à voir dans un feature kanban, moins dans la vie d'un développeur qui peut attendre de simple secondes, c'est lorsque l'opérateur regarde la machine. ### Muda of transport _Le transport est-il seulement utile ? Peut-on constamment se demander si nous pouvons ne pas l'éliminer directement ? En l'incluant dans la ligne de production ?_ La meilleure chose qu'une entreprise peut faire est de vendre ses convoyeurs à la compétition. Mieux ! Proposer gratuitement. _Qu'est-ce que le transport en informatique ?_ Les gaspillages de transport peuvent se voir dans ce qui est transporté : 1. Ne pas transporter de l'air, 2. ne pas stocker de l'air, 3. éliminer tout espace qui ne créer pas de valeur. La tâche d'éviter des muda se fait par l'ajout du suffixe anglais _-less_ dans les caractéristiques des conditions de travail : - search-less, - block-less, - air-less, - wait-less, - stop-less, - bottleneck-less, - stock-less, - reject-less, - careless mistake-less, - nonstandard-less, - ...-less. ### Muda of time Tout ça fait perdre du temps. ### Muda, Mura, Muri Les 3 `MU`s au Japon : - **M**uda : gaspillage, - **M**ura : variation, - **M**uri : surcharge. Ne pas accepter de la non qualité, ne pas faire de la non qualité, ne pas donner de la non qualité. ### Les 4-P - **P**eople involvement: - le top management sensibilisé, - créer des champions de kaizen, - former tous les employés, - **P**hysical workplace improvement: - implémentation du 5S, - management visuel, - **P**rocess improvement: - améliorer le ratio d'ajout de valeur, - **P**olicy review: _(moins clair)_ - revue de la régulation ## Chapitre 7 - The foundation of the house of _Gemba_ ### A learning enterprise Coopérer pour le bien de tous et pas seulement pour faire ce qu'on nous demande et récupérer le salaire mensuel. Les règles de mise en place : 1. Discard conventional rigid thinking about production. 2. Think of how to do it, not why it cannot be done. 3. Do not make excuses. Start by questioning practices. 4. Do not seek perfection. Do it right away even if only 50 percent of target. 5. Correct mistakes at once. 6. Do not spend money for Kaizen. 7. Wisdom is brought out when faced with hardship. 8. Ask "Why?" Five times, and seek the root cause. 9. Seek the wisdom of 10 people rather than the knowledge of 1. 10. Remember that opportunities for Kaizen are infinite. Results are improved by management who support the long term efforts of others. ## Chapitre 8 - visual management Rendre bien sûr visible les problèmes. La partie jidoka est extrêmement importante : si une ligne de production ne s'arrête jamais, soit elle est parfaite soit elle est extrêmement mauvaise. > A gemba team can use simple cardboard and paper labels to manage a very complicated production schedule and ensure good flow. L'utilisation de la heijunka pour planifier les demandes du client, la création d'un rôle d'araignée d'eau (mizusumashi _→ l'équivalent du coach agile ?_) sont des moyens sommaires pour répondre à un problème complexe d'organisation. Penser que l'organisation d'une équipe est simple est une erreur. Elle induit un cercle vicieux de penser que par défaut tout va bien se passer. C'est surtout l'inverse, et, ça provoque une tension lors d'échecs sur les personnes du gemba. Lorsque Jehane veut mettre un max sur des colonnes dans un outil, c'est qu'elle veut contrôler et qu'elle ne parle pas aux équipes. Le résultat du 5S c'est un meilleur management visuel qui rend visible les anormalités plus facilement. Est-ce que le management visuel présente des routines quotidiennes de Seiri, Seiton et Seiso ? > Some jobs can be very monotonous, but if we can give workers a sense of mission or a goal to aim at, interest can be maintained even in a monotonous job. Les objectifs rendent un travail fait et refait tout son intérêt. Nous sommes les marcheurs olympiques des applications mobiles. Tout le monde marche, certains vont extrêmement vites avec peu d'erreur même si la marche est une activité extrêmement monotone. **"Without targets, numbers are dead"**. Le fait de faire des kaizen porte tout son sens quand on voit qu'il est compris dans un objectif plus grand de l'entreprise. Ces objectifs doivent être visibles. > Kaizen activities become meaningful in the minds of gemba people as they realize that their activities relate to corporate strategies, and a sense of mission is instilled. ## Andon Les personnes doivent andon si elles se trouvent dans l'une de ces situations : - Le standard ne peut pas être suivis correctement, - il y a une différence entre le matériel des spécifications, - le cycle d'une machine est au-dessus du takt time, - un arrêt d'un fournisseur provoque l'attente d'un client, - un problème de qualité est détecté dans les process précédents lors d'un contrôle qualité. ## Chapitre 9 - The supervisors' roles in the gemba > Frequently, supervisors in the gemba do not exactrly know their responsabilities. They engage in such activities as firefighting, managing personnel issues, and achieving production quotas without regard to quality. Sometimes they don't even have daily production quotas in mind. Les problèmes au jour le jour peuvent être catégorisés comme suit : | Type | Nature | Pourcentage | Exemples | | ------ | ----------------------------------------------------------------------------- | ----------- | --------------------------------------------------- | | Type A | Les causes sont claires. Des contre-mesures peuvent être prises immédiatement | 70-80% | Standard non suivi. Manque de matériels | | Type B | Les causes sont connues mais des contre-mesures ne peuvent pas être adoptées. | 15-20% | Arrive lors d'ajustement de paramètres. | | Type C | Cause non identifiées | 10-15% | La situation devient soudainement hors de contrôle. | ### A day in the life of supervisor Audit, train and improve. Avec le Kamishibai, un gestionnaire des tâches pour de la maintenance préventive : on peut voir facilement les problèmes et les routines qui n'arrivent pas à être faites. > The group leader must motivate, train, and coach members on the kaizen program system so that each person is able to submit at least 12 ideas per year to improve safety, quality, productivity, and as a result, cost.\ > > The group leader also will audit specific systems like TPM, kanban system (he's the one picking up kanban card on the floor), adherance to standard work, setup times, and procedures. ## chapitre 11 - just in time ### un exemple de just in time La production de matelas commence après que la demande ai été faite. La carte Kanban qui été accroché au matelas revient au tout début de la ligne pour commencer la production. Parce que la production ne doit commencer que lorsque les commandes soient passées et que ce n'est pas possible. Cela demande d'avoir une stratégie de production. Aisin Seiki produit 40 matelas quotidiens par son expérience. Une des définitions du JIT est de réaliser uniquement les produits qui ont été commandés et dans la même séquence des commandes. ### Takt time vs cycle time Takt Time : le temps qu'il faut pour produire un matelas. Cela remet en question mon utilisation de ce terme. Le vrai takt Time que l'on doit vraiment suivre c'est le temps qu'il faut pour sortir une feature. Finalement le lead time ? (À BAM, il faudra juste diviser par le nombre de features sorties). **Le takt Time est connu de tous les opérateurs sur la ligne !** Quand les personnes ne le connaissent pas, ils n'ont aucune raison d'aller discuter avec les autres personnes. Et conduit à du push system, voir section suivante. Cycle time : le temps que met effectivement chaque opérateur. Le but du jeu est de se rapprocher le plus possible du takt Time. ### push production vs pull production Les équipes éloignées de la ligne d'assemblage entre elle vont avoir tendance à faire du push system : fabriquer autant que possible "au cas où". Ils n'arrêtent donc pas de continuellement créer des "work in progress". Voici mon problème en tant qu'EM, je ne vois pas cette ligne d'assemblage, je ne vois pas les stocks, je ne vois pas les problèmes de qualité. Ce qui crée du stock. Pour mieux faire mon travail, il me faut un feature Kanban à jour et un rituel avec les responsables. ### The introduction of JIT at Aisin Seiki L'utilisation du kanban a éliminé les inventaires, remplacés par des bacs bleus : un inventaire minimum qui ne s'accumule pas. Réduire le travail en cours doit être la priorité, c'est ce qui permet à l'équipe de mieux faire quasi immédiatement. Le "one piece flow" demande la synchronisation des équipes. #### Comment faire le JIT en informatique ? Lorsque finalement il n'y a qu'une seule demande : faire une application mobile ? Les demandes sont finalement multiples si on considère qu'une demande est un KPI. L'informatique est un bateau de Thésée, chaque ligne de code est un nouveau produit. On livre finalement très régulièrement, même tous les jours, un nouveau produit. #### Les réactions en JIT 1. Réagir à une commande client, 2. réagir à un manque dans un inventaire : les bacs bleus L'avantage des kaizen portés sur le JIT est la capacité d'améliorer des sujets fondés sur un bon besoin. Le lead time peut être une mesure à suivre systématiquement car on ne peut pas se tromper à vouloir réduire le temps de production. > C'est un crime de ne pas conduire un business sans lean. ### Total Flow Management L'introduction du flux tiré : kaizen tous les jours, partout et par tous. > [!NOTE] Est-ce que le flux tiré est autant important pour le kaizen ? > Oui, ça n'a même que peu de sens sans, l'équipe se retrouve avec beaucoup trop de variabilité et elle n'est pas dans les conditions de réussite. Le flux tiré est difficile à mettre en place mais pour ça on peut commencer par des flux internes. Être EM sur un projet, c'est être vu comme le CTO et le group leader de la tech, officiellement. Il faut réussir à provoquer des changements et créer ce lien avec tout le monde. ### 3 astuces pour le JIT 1. Changer l'état d'esprit des personnes est une partie critique du travail. Forcément sceptiques, il faut prendre des action drastiques et pérennes pour aller au-delà des objections. 2. le management doit diriger le changement, au début bien sûr, mais également en mettant continuellement la pression sur l'organisation. Si l'attention du leadserhip manque, alors le programme part de lui-même, 3. c'est un engagement long-terme, Il n'y a pas de fin. "- c'est bon, c'est fini ? - Pas encore" devra-t-on répondre. ## Chapitre 13 - the CEO's role in Kaizen > I have a theory: Most top managers, as they are promoted up the ladder, become more and more dumb. Why does that occur? Organizations are a pyramid. The value-added work is at the bottom, so the further you remove somebody from the value-added work, the less they know what's going on, because they're getting further away from what it is the business really does. And then the people down below try to protect them from bad news, so the bad news doesn't go up to the top very often, only the good news. And now the CEO is saying, "Well, everything is okay." > > Byrne Lorsque Byrne rachète une entreprise, il fait en sorte de lancer des kaizens dès les premiers jours. > They will be involved in our kaizen culture, whether they like it or not. There will be no grey zone. > > Byrne Le CEO dirige tous les premiers kaizen. Il montre l'exemple, encore et toujours. C'est quelque chose qui n'a pas à être vendu mais qui doit faire partie du travail de tout le monde. On l'impose car c'est dans la culture. Pendant toute la première semaine, Byrne fait du lean sur le gemba. > [!NOTE] Et en tant que prestataire ? > Dois-je prendre chaque nouveau client comme une nouvelle acquisition ? Et donc commencer par du kaizen dès le début ? Le lean est radical, le Juste à Temps est radical. L'idée majoritaire c'est qu'avoir des inventaires est le seul moyen d'amortir le coût et le temps de production de chacun. Donc les personnes ne vont pas croire ce que l'on propose et vont être réticentes. C'est leur demander l'impossible dans un contexte où l'argent est à risque. **La seule alternative est de montrer l'exemple.** General Motors, malgré leurs dires, n'est pas lean. Les questions qu'ils se posent sont de l'ordre du financier : - Le coût de la main d'oeuvre, - "puis-je négocier avec les syndicats ?", - "puis-je délocaliser ?". > [!NOTE] > Voici ce que je proposerai : un agenda commun à tous basé sur le TPS. Ça devient le rôle de l'EM de s'entretenir avec son équipe pour animer ces moments lean. L'EM liste et standardise les sujets de discussion. Une personne prépare et note tout dans une base de données partagée ou un board physique avec plusieurs niveau en fonction de la maturité des équipes à avoir des pièces et des exemples de performances (comme "# de fonctionnalités en cours de conception"). ❓ En revanche, comment faire pour rendre l'équipe focus et qu'elle arrive à faire du done ? Si c'est une bonne idée, elle demande plusieurs changements : 1. sales, 2. agenda, 3. disponibilité, 4. management visuel, 5. communication 1. asakai 2. café tech 6. l'EM ne doit pas produire mais soutenir concrètement la production > [!NOTE] > À propos de la WER et du _volume in_ : si on ne sait pas quoi faire d'une performance alors l'action ne doit pas être l'apathie comme actuellement mais de la recherche de théorie et d'expertise. --- ## Idées de note permanente - Close-call (Hiyari-hatto) Incidents Experienced during Daily Work

Still funny conversation with Claude - Durability before delivery

# Still funny conversation with Claude - Durability before delivery > Why a 10-second keystroke on a typewriter I'm building doesn't have to feel slow. I'm building a small device called **Typoena**: an e-ink panel, a mechanical keyboard, an ESP32-S3, and a single purpose. You open the lid, you write Markdown, you press a key to publish it to GitHub. There is no browser, no notification tray, no second app — the hardware enforces focus the way software can't. The whole product surface is two user-facing actions: - **Save** (`Ctrl-S`) — write the buffer to the SD card. ~200 ms. - **Publish** (`Ctrl-G`) — ship the working copy to the git remote. **5–10 seconds.** The same kind of keystroke, but one takes 50× longer than the other. The physical keypress is ~150 ms either way — key down, debounce, USB report, key up. On `Ctrl-S` that's _most_ of the perceived time; on `Ctrl-G` it's barely the first sliver of a long process. And the human perception threshold for "instant" is around 100 ms, so the gap isn't just a number on paper. Sitting with that, here's the concern I couldn't shake: > "I'm concerned about the fact that Ctrl-G is a 150ms action to do, but what it triggers can take >5-10s. Compared to the same quick action Ctrl-S for instance that will have a order of magnitude even lower than the pressing key action." :file-text-ai: The reframing question: **what is the user actually waiting for?** For `Ctrl-S`, the moment that matters is "my work is saved" — and the SD card completes the write in 50–200 ms. Save = safe. Same instant. For `Ctrl-G`, the equivalent moment isn't "push complete." It's "commit landed locally" — which happens at ~0.2 seconds, well before the push even starts. From that moment on, your work is preserved across power loss, SD removal, the apocalypse — everything except remote delivery. The remaining 5–10 seconds is _transport of an already-safe thing_. Surface that moment in the status line at ~0.2 seconds (`✓ committed abc1234 · pushing…`) and the perceived latency of `Ctrl-G` collapses from 10 seconds to roughly 200 milliseconds. The gap with `Ctrl-S` disappears. **Durability before delivery.** The moment that matters to the user is the moment durability is achieved, not the moment delivery completes. Once you see that, the slow operations stop feeling slow. _Postscript:_ that "commit lands in ~0.2 seconds" claim was true on my toy repo and a total lie on the real one — there it took **611 seconds** and never finished. Making it true is its own hunt. --- The _apocalypse_, haha!..

Material and Information Flow Analysis - MIFA

# Material and Information Flow Analysis - MIFA MIFA is a way to perceive and analyze the complexity of reality (even if all models are wrong). Done well, this analysis reveals the inflexibilities in the way we work. It is the power of a map to show us what we don't yet know. Through the gemba, the MIFA is filled in gradually to avoid reifying people. ## What we want to see in a MIFA - A takt - A lead time: min / max to observe variability. (⚠️ The average removes this information) - A material flow (the machine or the activity) - An information flow - Kaizen opportunities - The presence of a push flow or a pull flow > MIFA seeks to answer the question: "How can I cut inventory in half? Who do I need to coordinate with to get there?". Look how close cash, information and material flows are with each other --- ## My learnings from the France Identité Numérique MIFA - Consider the Takt: 8h × 60 minutes → 480 minutes / number of products that must come out. - 1 per month - Push movement of parts - Oral instructions — nothing written down to know who should do what (if it's unclear, put on your glasses) - Where the checkpoints are and where there aren't any - Truck prep plan with the 4 P1, P2, P3, P4 - Pull flow - FIFO - What matters is what triggers this part - Also capture people's misconceptions up front: "When do you fill them?" — "We only do it at night so they have nothing to do during the day", but actually it doesn't help at all - Cyril went to the field with a piece of paper and then built the MIFA back at the office. --- ## References - VSM vs MIFA - Pas d'amélioration de l'organisation sans MIFA | Michael Ballé > Material and Information Flow Analysis, or MIFA, is a simple but powerful way to look at lead-time inside a plant—not by starting with production, but by focusing first on withdrawal and conveyance, and what information triggers these movements. In many factories, materials are moved around without much thought, often in big batches and then laid to rest where they arrive. MIFA starts by asking: Who takes what, from where, and when?—and just as importantly, What signal tells them to do it? > > Toyota engineers learned something surprising: if you increase how often you withdraw parts—even without changing batch sizes—you actually reduce the inventory you need to hold. Why? Because frequent withdrawal creates a natural rhythm that stabilizes the flow. It makes problems more visible and forces teams to react faster. Of course, to go further, you eventually have to reduce batch sizes as well, to move closer to true single-piece flow—the lean ideal. > > MIFA invites you to ask a few key questions: > > 1. First, does your production pace match your sales pace? If not, you’re probably building too much of what you can’t sell and not enough of what you can. > 2. Second, are the product references going to a shop stock stable, or are they unpredictable? Unstable references drive up buffer stocks and chaos. > 3. Third, is the production cell itself reliable enough to run in smaller batches, or even one piece at a time? These questions shift the improvement focus from production efficiency to flow efficiency—which is where lead-time really lives. > > MIFA doesn’t just map the plant; it reveals the logic behind the flow, shows how most material issues are created by how the information is structured and shared (what are the timetables? What increments? How stable is the demand?), which helps teams redesign their system to be faster, leaner, and more responsive—by seeing what triggers what, and whether the rhythm matches customer demand. > > The deep insight behind the MIFA is that you control your plant through logistics first, rather than actual production, because a plant’s real job is to deliver (good parts on time) rather than simply produce. > > Michael Ballé Private MIFA examples.

Reifying must go through communication with people

# Reifying must go through communication with people Whether in a software program or a team setup, when we file a person away we can "mistreat" them because we dehumanize them. In the sense that we manipulate a person's data in a way we would not do with that person directly. We reduce a person to a single data point: their role, their skills. ## Examples The computer is "fatal", meaning you cannot negotiate with it and the user is _de facto_ seen as a reification. --- ## References > reification: in philosophy, the process by which something moving and dynamic is transformed into a fixed, static being. @youtube - Cloud souverain - Géopolitique de la data - Benjamin Bayart à USI | USI Events - Accounting for slavery | Caitlin Rosenthal - Job relations

Faire un bon gemba walk

# Faire un bon gemba walk > Tu fais du bon travail, merci. Sur quoi tu as besoin d'aides ? C'est l'occasion où on est tous présent. > > - Akio Toyoda, PDG de Toyota, faisant la revue des A3 avec tous les grands managers autour d'un team member ## Intention Le gemba est fondamental : il est là où se produit la valeur. C'est une activité exigeante pour le manager. Le regard du vrai se perd au fur et à mesure qu'on s'en éloigne. C'est la source de lien avec les personnes et, en tant que manager, il permet de comprendre les faits qui nous freinent ou qui font notre réussite. La compétence à avoir en tant que manager est une liste de méthodes d'analyse à collectionner. On devient bon en PDCA. Aller sur le gemba est une preuve que les managers ne font pas l'économie du social pour réussir et est le premier élément d'une transformation lean. ## Points clefs | Principe | Explication | | ------------ | ------------------------------------------------------------------------ | | **E**nergize | Valider et avoir du _care_ pour la personne | | **E**ducate | Expliquer un principe, donner des perspectives | | **E**ngage | Réduire à un problème concret et faire de la résolution de problème | | **E**nable | Donner **la permission** qu'ils peuvent contribuer et apporter de l'aide | - voir ce que les yeux, les mains et les pieds font lorsque les personnes travaillent, - le temps pour trouver le point de blocage ne devrait pas être plus élevé qu'une minute → remonter la barre d'exigence, voir où ils s'éteignent et montrer que l'on peut faire mieux est le point crucial du gemba walk, - identifiés les gestes utilisés et les écarts aux standards, - Genchi Gembutsu : visualiser la pièce de ses propres yeux, la toucher de ses propres mains, - vérifier sur quoi on accorde de l'importance : à la compétence, à la soumission à l'autorité ou aux imprévus poussés par les personnes les plus stressées ? > [!NOTE] > Lors d'un trop gros écart, il est possible d'arrêter l'observation pour remettre au standard. ## Erreurs à éviter - être trop gentil → il s'agit d'un deal à passer, en tant que leader je dois donner. Mais si on ne donne rien en retour, je dois sélectionner et je ne peux pas me faire avoir longtemps. Voir sur la théorie des jeux la coopération, la réciprocité et le pardon, - lorsque on sent qu'on est dans la mélasse c'est que c'est un gemba walk qui se passe mal, - le faire avec des personnes qui n'ont aucune envie d'apprendre. S'il y a systématiquement un refus d'obstactle alors le gemba walk sera pénible et utile pour personne. Est-ce qu'ils écoutent ? Est-ce qu'ils font confiance ? --- ## Références - Le gemba, - Gemba Kaizen, - Les 3 violences. @youtube - What Game Theory Reveals About Life, The Universe, and Everything | Veritasium

The Tragedy of the Commons

# The Tragedy of the Commons :share: The tragedy of the commons is the opposition between individual needs (short-term) and collective needs (long-term). It happens when individuals' needs are not aligned with the group's needs. An individual overexploits a resource for their own benefit, at the expense of the collective in the long term — and if everyone behaves the same way, that resource will eventually disappear. Here, everyone ends up losing. > Local benefits, global side effects. Henkaten This tragedy emerges when the system's feedback is delayed: erosion is slower than exploitation. For example, the atmosphere fills up with CO₂ faster than the climate changes. This tragedy leads to systematic overshoot beyond what a stock can renew — and therefore to its complete destruction if nothing is done. ## How to avoid it? 1. Regulate, 2. Educate, 3. Exhort / commit: social contracts are one way out. Acknowledging the scale of the problem and agreeing as a society on appropriate individual behavior can help us avoid long-term consequences. > What is good for everyone is good for each. ## Examples of shared goods - renewable resources limited by their inflow rate: like food, - the surrounding air: cars are convenient for getting around but produce undesirable side effects through pollution, - bottled water in plastic. --- ## References @youtube - What is the tragedy of the commons? - Nicholas Amendolare | TED-Ed

Henkaten - when our solution becomes others' problem

# Henkaten - when our solution becomes others' problem Being able to anticipate the problems caused by a change is a mark of seriousness. It means wanting to solve a global problem rather than locally optimizing just to spare ourselves the inconvenience. Doing henkaten is the best way to succeed in our projects. --- ## References - The right kind of wrong, - Scout mindset - Chapitre 8 - All about lean - Henkaten - The Tragedy of the Commons

Ishikawa Diagram

# Ishikawa Diagram The ishikawa diagram looks at the first causes of an effect or problem. It frames it so it's easy to widden the thinking about 4M: Man, Machine, Method, Material.