Toyota es conocida como la organización más eficiente en el planeta fuera del cuerpo humano, y una de sus filosofías es evitar la documentación. En lugar de hacer un "proceso" para cuando alguien en la línea de montaje necesita más pernos, simplemente tienen 5 bandejas de pernos en su estante y cuando uno está vacío lo sacan del estante y alguien viene cada hora y rellena todos los estantes desde atrás. No es necesario documentar nada, el proceso lo hace por usted.
Hubo un artículo reciente sobre Cuarzo que habló sobre la atención de Apple a las listas de verificación.
Resulta que la clave de la creatividad, velocidad y adaptabilidad de Apple es, en su superficie, exactamente lo opuesto al tipo de creatividad de rueda libre que uno podría esperar. Es una lista de verificación ... muy larga.
Lo cual me hizo pensar acerca de mi filosofía sobre las listas de verificación. Hay muchas cosas incorrectas en las listas de verificación. Se ponen fuera de fecha. Pueden ser largos y aburridos y repetitivos. Al igual que todas las métricas, pueden enfocarse en las cosas equivocadas. Pero todas esas cosas son ciertas también al omitir las listas de verificación, ¿verdad? Me refiero a la tercera vez que ha cometido el mismo error, probablemente sea hora de admitir que seguir una lista de verificación podría haberle ahorrado tiempo.
Pero las listas de verificación solo son buenas si se aplican y se actualizan con frecuencia, y usted sigue estando al antojo de un ser humano que, seamos sinceros, no están diseñados para ser perfectos todo el tiempo.
Tenemos un estándar Drupal Instalamos para la mayoría de los clientes que están en Drupal. Esto incluye módulos, configuraciones, usuarios predeterminados y nuestros datos de prueba predeterminados. Solía ser una lista de verificación, pero siempre estaba desactualizada. Entonces alguien entró y lo hizo tan específico que cualquier persona con un conocimiento limitado de Drupal podría hacerlo, así que todos los drupal recalcitrantes en la tienda lo odiaron, así que lo eliminamos, y luego no pudimos entrenar a nadie nuevo. en él y solo los desarrolladores mayores de Drupal podrían seguirlo, entonces comenzamos a codificarlo Drush.
Drush significa que cualquier persona con experiencia en Drupal podría ejecutar un par de líneas de código y todo "pasaría" mágicamente. No más "error humano", es una lista de verificación, pero en lugar de un humano desordenado tratando de seguir una lista de verificación, una computadora lo siguió.
El problema con eso era que incluso el cambio más simple necesitaba un desarrollador y cada cambio tenía que probarse, por lo que se desintegró rápidamente.
Finalmente nos encontramos con la solución obvia, que es algo difícil de codificar en Drush, lo que hizo que sea algo difícil de cambiar.
Ahora simplemente tenemos un sitio llamado "clonarme" o algo así y cada vez que tenemos un nuevo cliente, simplemente lo duplicamos. Cambiarlo solía involucrar a un programador y muchos otros trabajos, ahora cualquiera con la contraseña de nuestro equipo puede ir y cambiar algo. Si un diseñador desea diferentes datos de prueba, lo cambian y estará automáticamente en nuestro próximo proyecto. Si un PM decide que necesitamos otro usuario predeterminado para fines de capacitación, crean uno y estará en nuestro próximo proyecto.
"La primera vez que haces algo simplemente hazlo". La segunda vez, hazlo y toma notas. La tercera vez, deténgase y vea si realmente es lo mismo. Si se trata de hacer un proceso, probablemente habrá un cuarto y un quinto, y así sucesivamente. "- Gavin Andresen, CTO Bitcoin
Tuvimos la suerte de tener a Gavin aquí en Gravity Switch durante unos años. Él contribuyó bastante a nuestra cultura y nuestro código, pero su sabiduría acerca de cuándo "piratear" las cosas y cuándo procesarlas es algo que realmente ha cambiado la forma en que abordo la documentación.
Gavin nos enseñó que el buen código es autodocumentado.