Toyota staat bekend als de meest efficiënte organisatie op de planeet buiten het menselijk lichaam, en een van hun filosofieën is om documentatie te vermijden. In plaats van een "proces" te maken voor wanneer iemand op de assemblagelijn meer bouten nodig heeft, hebben ze eenvoudigweg 5 bins bouten op hun plank en wanneer er een leeg is, verplaatsen ze het van de plank en komt er iemand elk uur langs en vult alle planken opnieuw vanaf de achterkant. U hoeft niets te documenteren, het proces doet het voor u.
Er was een recent artikel over Quartz die sprak over Apple's aandacht voor checklists.
Het blijkt dat de sleutel tot de creativiteit, snelheid en aanpassingsvermogen van Apple op het eerste gezicht precies het tegenovergestelde is van het soort vrije creativiteit dat je zou kunnen verwachten. Het is een checklist ... een hele lange.
Wat me deed nadenken over wat mijn filosofie over controlelijsten is. Er is veel mis met checklists. Ze raken verouderd. Ze kunnen lang en saai en repetitief zijn. Zoals alle statistieken kunnen ze zich concentreren op de verkeerde dingen. Maar al die dingen kloppen ook met het overslaan van checklists, toch? Ik bedoel, de derde keer dat je dezelfde fout hebt gemaakt, is het waarschijnlijk tijd om toe te geven dat het volgen van een checklist je tijd heeft bespaard.
Maar checklists zijn alleen goed als ze van toepassing zijn en ze worden vaak bijgewerkt, en je bent nog steeds in de grillen van een mens die, laten we eerlijk zijn, niet altijd perfect gebouwd is.
We hebben een standaard Drupal installeren we beginnen met voor de meeste klanten die op Drupal zijn. Dit omvat modules, instellingen, standaardgebruikers en onze standaard testgegevens. Het was vroeger een checklist, maar deze was altijd verouderd. Toen ging iemand naar binnen en maakte het zo specifiek dat iemand die zelfs met beperkte kennis van Drupal het kon doen, dus alle die-hard Drupal-mensen in de winkel het haatten, dus namen we dat uit, en dan konden we niemand nieuw trainen erop en alleen oudere Drupal ontwikkelaars konden het volgen, dus toen zijn we begonnen met het hard coderen Drush.
Drush betekent dat iedereen met Drupal-ervaring een paar regels code zou kunnen uitvoeren en dat alles op magische wijze zou gebeuren. Geen "menselijke fout" meer, het is een checklist, maar in plaats van een rommelige mens die een checklist probeert te volgen, volgde een computer.
Het probleem was dat zelfs de eenvoudigste verandering een ontwikkelaar nodig had en dat elke verandering getest moest worden en dus viel het snel uit elkaar.
Uiteindelijk kwamen we de voor de hand liggende oplossing tegen, die iets hardgecodeerd is in Drush, waardoor het enigszins moeilijk was om te veranderen.
Nu hebben we gewoon een site genaamd "kloon me" of iets dergelijks en wanneer we een nieuwe klant hebben, dupliceren we het gewoon. Bij het veranderen ervan was een programmeur en veel ander werk betrokken, nu kan iedereen met het wachtwoord van ons team iets gaan veranderen. Als een ontwerper andere testgegevens wil, wijzigen deze deze en wordt deze automatisch in ons volgende project opgenomen. Als een premier besluit dat we een andere standaardgebruiker nodig hebben voor trainingsdoeleinden, maken ze er een en dit zal in ons volgende project zijn.
"De eerste keer dat je iets doet, doe het gewoon. De tweede keer, doe het en maak aantekeningen. De derde keer, stop en kijk of het echt hetzelfde is. Als het er een proces van maakt, want er zal waarschijnlijk een 4e en een 5e zijn, enzovoort. "- Gavin Andresen, CTO Bitcoin
We hadden het geluk om Gavin een paar jaar bij Gravity Switch te hebben. Hij heeft heel wat bijgedragen aan onze cultuur en onze code, maar zijn wijsheid over wanneer je dingen moet "hacken" en wanneer je ze moet procedureren, is echt veranderd in de manier waarop ik documentatie benader.
Gavin heeft ons geleerd dat goede code zelfdocumenteert.