Toyota är känd som den mest effektiva organisationen på jorden utanför människokroppen, och en av deras filosofier är att undvika dokumentation. I stället för att göra en "process" för när någon på monteringsledningen behöver fler bultar, har de helt enkelt 5 fatbultar på hyllan och när en är tom flyttar den bort från hyllan och någon kommer varje timme och fyller på alla hyllor från baksidan. Det finns inget behov av att dokumentera någonting, processen gör det för dig.
Det var en den senaste artikeln om kvarts som pratade om Apples uppmärksamhet på checklistor.
Det visar sig att nyckeln till Apples kreativitet, fart och anpassningsförmåga är på sin yta, det exakta motsatsen till den typ av frihjulande kreativitet man kan förvänta sig. Det är en checklista ... en riktigt lång en.
Vilket fick mig att tänka på vad min filosofi om checklistor är. Det finns mycket fel med checklistor. De blir föråldrade. De kan vara långa och tråkiga och repetitiva. Liksom alla mätvärden kan de fokusera på felaktiga saker. Men alla dessa saker är sanna för att hoppa över checklistor också, eller hur? Jag menar tredje gången du har gjort samma misstag, det är förmodligen dags att erkänna att en checklista kanske har sparat dig tid.
Men checklistor är bara bra om de gäller och de uppdateras ofta, och du är fortfarande på infall av en människa som, låt oss möta det, inte är byggd för att vara perfekt hela tiden.
Vi har en standard Drupal installera vi börjar med för de flesta kunder som finns på Drupal. Detta inkluderar moduler, inställningar, standardanvändare och våra standardtestdata. Det brukade vara en checklista, men det var alltid föråldrat. Då gick någon in och gjorde det så specifikt att alla som ens med begränsad kunskap om Drupal kunde göra det, så hatade alla Drupal-folk i butiken det, så vi tog det ut och då kunde vi inte träna någon ny på det och endast senior Drupal devs kunde följa det, så då började vi med att koda det Drush.
Drush betyder att alla med Drupal-erfarenhet kan köra ett par rader kod och allt skulle "hända" magiskt. Inget mer "mänskligt fel", det är en checklista, men i stället för en rörig människa som försöker följa en checklista följde en dator den.
Problemet med det var att även den enklaste förändringen behövde en utvecklare och varje förändring måste testas och så föll den ganska snabbt.
Så småningom kom vi över den uppenbara lösningen, vilket är något svårkodat i Drush, vilket gjorde det lite svårt att ändra.
Nu har vi helt enkelt en webbplats som heter "klon mig" eller något sådant och när vi har en ny klient duplicerar vi bara det. Ändra det brukade involvera en programmerare och mycket annat arbete, nu kan alla som har lösenordet på vårt team gå och ändra något. Om en designer vill ha olika testdata ändrar de den och det kommer automatiskt att vara i vårt nästa projekt. Om en PM bestämmer att vi behöver en annan standardanvändare för träningsändamål skapar de en och det kommer att vara i vårt nästa projekt.
"Första gången du gör något gör du bara det. Andra gången, gör det och ta anteckningar. Tredje gången, sluta och se om det verkligen är detsamma. Om det är en process ut av det för att det förmodligen kommer att vara en 4: a och 5: e och så vidare. "- Gavin Andresen, CTO Bitcoin
Vi hade turen att ha Gavin här på Gravity Switch i några år. Han bidrog ganska mycket till vår kultur och vår kod, men hans visdom om när man ska "hacka" saker och när man ska procedurera dem är något som verkligen förändrats när jag närmar sig dokumentation.
Gavin lärde oss att bra kod är självdokumentation.