Get best of the week

¿Por qué estamos escribiendo programas de tan mala calidad?


:
— , ,  — .
- :
— . .
:
— .
— ?
— . , .
— ?
— , , , , , .
- Dicen que la confiabilidad está garantizada por una tecnología llamada blockchain.
- Ahhhhhhhh !!! Lo que digan, ¡no lo toques! Excavar más hondo. ¡No te olvides de los guantes!
Fuente: XKCD , licencia Creative Commons 2.5. Una

falla en la aplicación de conteo móvil de la semana pasada causó estragos en el Congreso del Partido Demócrata de Iowa. Unas pocas horas después de la apertura de las reuniones en todo el estado, quedó claro que algo había salido mal. Los resultados aún se desconocen. Hubo mensajes que describían problemas técnicos y malentendidos. El Partido Demócrata de Iowa emitió una declaración que niega los rumores de un ataque cibernético, pero confirma problemas técnicos con la aplicación móvil.

Una semana después, ya entendemos mejor lo que sucedió. Se escribió una aplicación móvil específicamente para este evento en Iowa. Se distribuyó como una versión beta , sin pasar por grandes directorios de aplicaciones. Los usuarios sufrieron, pero lucharon para que el programa funcionara. Después de la instalación, era muy probable que no respondiera a las llamadas. En algunos lugares de reunión, no había conexión a Internet, lo que hacía que la aplicación en línea fuera inútil. Los demócratas tenían un plan de respaldo: informar los resultados por teléfono, como de costumbre. Pero las líneas telefónicas estaban repletas de trolls en línea, lo que las atascó por el bien de Lulz.

Twitter siguió a una ola de hashtags #app y #problems, y los ingenieros de software citaron a KDPV. Yo también pensé lo mismo. Las palabras de esta caricatura resumen bien el sentimiento general de lo que está sucediendo: "No sé cómo expresarlo, pero toda nuestra área es mala en lo que hacemos, y si confías en nosotros, todos morirán". Los ingenieros de software no lo dicen directamente. Pero suena muy similar. A que nos referimos

Esto es lo que queremos decir: hacemos bien el software, siempre que las consecuencias de la falla no importen. En promedio, los programas son lo suficientemente buenos como para funcionar de alguna manera. Sin embargo, no estamos particularmente sorprendidos por los errores en la mayoría de los programas. Estos no son algunos incidentes raros. Muchas prácticas comunes en la ingeniería de software provienen del supuesto de que los bloqueos son la norma y, lo más importante, las nuevas características. El fracaso es realmente barato. Si el servicio en línea de una de las compañías más grandes se desconecta por completo durante dos horas, lo olvidarán en una semana. Esta suposición se materializa en los mantras comunes: "Muévete rápido y rompe todo" (Muévete rápido y rompe cosas), "Desplázate y repite el ciclo" (lanzar e iterar).

El mercado recompensa generosamente por tal comportamiento "irresponsable". En muchas compañías web, una pequeña ganancia por usuario se multiplica por millones (¡o miles de millones!) De usuarios. Esto es beneficioso para las empresas con aplicaciones de consumo o sitios web. La implementación es costosa, pero el costo es finito y la distribución es casi gratuita. La industria del software de consumo ha encontrado un compromiso: estamos reduciendo la velocidad de implementación lo suficiente para mantener nuestro nivel de defectos moderadamente bajo, pero no demasiado.

Llamamos a dicho desarrollo de software el "modelo económico de un sitio web": cuando los beneficios de la implementación son altos y el costo de los reintentos es bajo, la administración fomenta la liberación de funciones a alta velocidad. Esto se refleja en las prácticas modernas de gestión de proyectos y su implementación, que analizaré a continuación.

Pero, como dije, "hacemos bien el software, siempre que las consecuencias del fracaso no importen". Este enfoque lleva a fallas terribles si las consecuencias no son baratas, como en Iowa. La práctica común del desarrollo de software ha surgido del modelo económico de Internet, y cuando se violan los supuestos de este modelo, los ingenieros de software hacen un mal trabajo.

¿Cómo funciona la programación en las empresas web?


Imagine la compañía hipotética QwertyCo. Es una compañía de software orientada al consumidor que gana $ 100 millones al año. Podemos estimar el tamaño de QwertyCo comparándolo con otras compañías. WP Engine, el alojamiento de WordPress, alcanzó ARR de $ 100 millones en 2018 . Blue Apron generó $ 667 millones para el año . Por lo tanto, QwertyCo es una empresa mediana. Tiene de varias docenas a varios cientos de ingenieros y no emitió acciones en circulación pública.

Primero, considere la economía de la gestión de proyectos en QwertyCo. Los líderes han aprendido que no desea anunciar instantáneamente una nueva función. Tiene un compromiso entre la calidad del software, la fecha límite y la velocidad de implementación.

¿Qué tan importante es la calidad del software para ellos? Realmente no. Si el sitio web de QwertyCo no funciona las 24 horas del año, estiman la pérdida en solo $ 273,972 (suponiendo que el tiempo de actividad esté correlacionado linealmente con los ingresos). Dicen que el sitio a menudo se desconecta durante 15 minutos, y a nadie realmente le importa. Si la función bloquea el sitio, lo revertirán y volverán a intentarlo más tarde. Los intentos repetidos son baratos.

¿Qué tan valiosa es la nueva característica para QwertyCo? Según mis observaciones personales, un mes de trabajo de un ingeniero puede cambiar los ingresos de un sitio optimizado en el rango de -2% a 1%. Esta es una oportunidad mensual de obtener $ 1 millón de ingresos adicionales de QwertyCo para cada ingeniero. Los métodos como las pruebas A / B incluso mitigan los errores: en unas pocas semanas, puede detectar cambios negativos o neutrales y eliminar estas características. Las malas características son baratas: están activas durante un período de tiempo limitado. Ganar se obtiene para siempre. Incluso un bajo porcentaje de apuestas ganadoras genera ganancias en QwertyCo.

Dados los pros y los contras, ¿cuándo debería QwertyCo lanzar una función? El cálculo económico muestra que incluso las funciones de alto riesgo deberían iniciarse si a veces obtienen ganancias. En consecuencia, cada proyecto se convierte en un juego de optimización: “¿Cuánto se puede implementar para esta fecha?”, “¿Cuánto tiempo se requiere para implementar todo el proyecto? ¿Qué pasa si quitas X de él? ¿Qué pasa si eliminas X e Y? ¿Cómo acelerar la implementación de una parte determinada? ”

Ahora considere un proyecto de software desde el punto de vista de un ingeniero de software.

Su principal recurso es el tiempo. El desarrollo seguro de software lleva mucho tiempo. Tan pronto como un producto cruza un cierto umbral de complejidad, tiene varias etapas de desarrollo (incluso si no pasan como parte de un proceso explícito). Deben planificarse con la ayuda del gerente de producto. El producto se convierte en un proyecto o plan técnico, si es necesario, se divide en subtareas. Luego se escribe un código con pruebas, se realiza una revisión del código, se registran estadísticas, el producto se integra con paneles de información y alertas. Si es necesario, se realizan pruebas manuales. Además, la codificación a menudo tiene una sobrecarga adicional conocida como refactorización.: Modificar un sistema existente para facilitar la implementación de una nueva característica. En la implementación de la función "pequeña", la codificación en sí puede tomar solo del 10 al 30% del tiempo.

¿Cómo pierden el tiempo los desarrolladores? Muy a menudo se trata de fallas del sistema. Durante el tiempo de inactividad del sitio, todo está incluido en el trabajo. Los ingenieros más experimentados detienen los proyectos en curso para volver a encarrilar el sitio. Pero el tiempo necesario para extinguir un incendio es el momento en que no aportan beneficios adicionales a la empresa. Sus proyectos están retrasados. ¿Cómo reducir el tiempo de inactividad? Las pruebas escritas, el monitoreo, las notificaciones automáticas y las pruebas manuales reducen el riesgo de eventos catastróficos.

¿De qué otra manera pierden el tiempo los ingenieros? A través de errores más sutiles y raros. Algunos errores aparecen raramente, pero causan grandes daños. Quizás los usuarios pierdan datos si realizan una determinada secuencia de acciones. Cuando un ingeniero recibe un informe de tal error, debe abandonar todo y arreglarlo. Esto distrae del proyecto actual y gradualmente puede aumentar el tiempo de inactividad.

En consecuencia, los ingenieros de software experimentados comienzan a prestar mucha atención a la calidad del código, quieren verificarlo cuidadosamente. Es por eso que las organizaciones de ingeniería usan métodos que a primera vista ralentizan la velocidad de desarrollo: análisis de código, integración continua, observabilidad, monitoreo, etc. Los errores son más baratos si los detecta en una etapa temprana, por lo que los ingenieros invierten mucho en la detección temprana de errores . También se centran en la refactorización, lo que simplifica la implementación. En una implementación más simple, hay menos posibilidades de error.

Por lo tanto, la gestión y el desarrollo tienen puntos de vista opuestos sobre la calidad. El manual está de acuerdo con una alta tasa de error (pero no demasiado alta), y los ingenieros quieren que el error sea un mínimo absoluto.

¿Cómo afecta esto a la gestión de proyectos? Los gerentes y desarrolladores dividen el proyecto en pequeñas tareas. El tiempo de entrega del proyecto depende de la cantidad de tareas y la cantidad de ingenieros. Muy a menudo, un proyecto lleva demasiado tiempo, y se ajusta eliminando funciones. Luego los ingenieros realizan las tareas. La realización de la tarea a menudo se realiza dentro del sprint.. Si el tiempo de sprint es de dos semanas, cada tarea tiene un temporizador implícito de dos semanas. Sin embargo, las tareas suelen llevar más tiempo de lo que piensas. Los ingenieros toman decisiones difíciles de priorización para terminar a tiempo: "Puedo hacer esto al final del sprint si escribo pruebas básicas y si omito esta refactorización que estaba planeando". Los sprints ejercen una presión constante, empujando al desarrollador. Esto significa que el ingeniero puede comprometer la calidad o admitir el fracaso en la próxima reunión.

Algunos dirán que soy demasiado duro con los sprints, y tienen razón. De hecho, todo esto se debe a la presión del tiempo. El proceso de sprint es solo una forma conveniente de aumentar esta presión al aplicarlo varias veces: una vez durante la evaluación de todo el proyecto y otra para cada tarea. Si el producto se valora al valor agregado para la empresa, es natural que el tiempo de implementación se ajuste por sí mismo. Los ingenieros también están interesados ​​en una implementación rápida, pero a menudo intentan optimizar los costos a largo plazo, en lugar de a corto plazo. Sin embargo, muchas organizaciones a menudo solo estimulan la velocidad actual a corto plazo.

Una vez establecidos dichos incentivos, el gerente recibe lo que quiere: puede nombrar la función y la fecha futura, y la gerencia y los desarrolladores discutirán cómo hacerlo. "Quiero que realice compras con un clic dentro de dos meses sin crear una cuenta". Los gerentes y desarrolladores escribirán todas las tareas durante dos semanas y acortarán la lista hasta que puedan iniciar la función llamada "compras con un solo clic". Ella tendrá un riesgo moderado de falla y probablemente solo funcionará después de algunas iteraciones. Pero el fracaso es temporal y la función es para siempre.

¿Qué sucede si se violan los supuestos de tal modelo económico?


Como dije, hacemos bien el software, siempre que las consecuencias de la falla no importen. Esto se indica mediante los lemas "Muévete rápido y rompe todo", "Desplázate y repite". Pero todos pueden imaginar una situación en la que rehacer es costoso o incluso imposible. En caso de apuro, el derrumbe de un edificio puede matar a miles de personas y causar daños por miles de millones de dólares. El Congreso de Facciones de Iowa 2020 es un ejemplo más suave. Si el evento falla, por la tarde todos irán a casa con vida. Pero la fiesta no puede organizar estas reuniones por segunda vez ... sin gastar mucho tiempo, dinero y esfuerzo.

Nota breve: en esta sección utilizo la frase "alto riesgo" como abreviatura de "situaciones con imposibilidad de volver a intentar" y "situaciones con una posibilidad costosa de volver a intentar".

¿Qué sucede cuando se aplica un modelo de sitio económico en una situación de alto riesgo? Tomemos un ejemplo al azar: digamos que está escribiendo una solicitud para informar sobre los resultados de una reunión en Iowa. ¿Qué pasos tomará para escribir, probar y probar la aplicación?

Primero, la logística de ingeniería: debe escribir tanto una aplicación de Android como una aplicación de iPhone. La presentación de informes es un requisito central, por lo que se necesita un servidor. Las reglas de recopilación confusas deben codificarse tanto en el cliente como en el servidor. El sistema debe informar los resultados al usuario final; Esta es otra interfaz que necesita ser programada. El Partido Demócrata probablemente tenga requisitos de validación y presentación de informes que debe escribir a la aplicación. Además, será muy inapropiado si el servidor falla durante la reunión, por lo que debe implementar algún tipo de sistema de monitoreo.

A continuación, ¿cómo verificar la aplicación? Una opción es la prueba del usuario. Muestra imágenes de una aplicación hipotética a usuarios potenciales y hace preguntas como "¿Qué crees que hace esta pantalla?" y "Si quieres llegar a $ a_thing, ¿dónde harás clic?" El diseño siempre requiere varias iteraciones, por lo que es razonable esperar alta calidad después de varias rondas de tales pruebas. Las grandes empresas suelen pasar varias rondas antes de introducir características importantes. A veces incluso cancelan funciones después de recibir comentarios antes de escribir al menos una línea de código. Las pruebas de usuario son baratas. ¿Es difícil encontrar cinco personas que pasen 15 minutos en el cuestionario, después de haber recibido una tarjeta de regalo por cinco dólares como regalo? En nuestro caso, lo más difícil es hacer una muestra representativa,que corresponde a los representantes democráticos de Iowa.

Luego debe verificar la aplicación en acción: instálela y configúrela en su teléfono inteligente. El Partido Demócrata debe entender cómo obtener resultados. En caso de falla, necesita un plan de respaldo. Una buena prueba puede incluir una "reunión de prueba", donde varios miembros del Partido Demócrata de Iowa descargan la aplicación e informan los resultados a un servidor central en una fecha determinada. Esto identificará problemas y describirá la situación general. La verificación se puede llevar a cabo por etapas a medida que se introducen partes individuales del producto.

Además, Internet está lleno de villanos. Por ejemplo, los grupos rusos difundieron información errónea ampliamentea través de las redes sociales como Facebook, Reddit y Twitter. Por lo tanto, debe asegurarse de que no intervenga ningún extraño. ¿Cómo verificar la autenticidad de los resultados? Además de los villanos, Internet está lleno de bromistas que están listos para interrumpir cualquier evento solo por diversión . ¿Cómo resiste nuestro sistema los ataques DDoS? Si no, ¿hay un plan de respaldo? ¿Quién es responsable de presentar un plan alternativo al informar esto en las reuniones? ¿Qué sucede si las cuentas de miembros son pirateadas? Si la empresa no tiene expertos en seguridad, es probable que la aplicación se someta a una auditoría independiente.

Además, ¿cómo garantiza que no haya ningún error en el software que distorsione los resultados? En consecuencia, el Partido Demócrata debería sospechar de sí mismo: ¿es posible creer los resultados si hay un traidor en sus filas? Los resultados deben estar disponibles para su verificación mediante copias en papel.

Bien, dejemos de enumerar problemas. Una cosa está clara: lleva mucho tiempo y recursos asegurarse de que todo funcione.

Los creadores de la aplicación Iowa Caucus recibieron $ 60,000 y dos meses. Tenían cuatro programadores. Esta cantidad no es suficiente para pagar cuatro buenos programadores y otros gastos. El dinero no se puede cambiar por tiempo. Prácticamente no hay ayuda externa.

Imagine que está utilizando la práctica generalmente aceptada de eliminar tareas de un proyecto hasta que la línea de tiempo sea factible. Harás todo lo posible para ahorrar tiempo. Una vista previa del catálogo de aplicaciones a menudo lleva menos de un día, pero en el peor de los casos, puede durar una semana y la solicitud puede ser rechazada. Así que omita esto: los miembros demócratas descargarán la aplicación a través de enlaces beta. Incluso con un control de seguridad gratuito, tomará demasiado tiempo cumplir con todas sus recomendaciones. Por lo tanto, rechazamos el control de seguridad. Quizás, durante el desarrollo del backend, le pagó al diseñador $ 1000 por crear el diseño de la aplicación y el logotipo. Planea una ronda de pruebas de usuario (pero luego omítela cuando venzan los plazos).¡Desplácese rápidamente y repita el ciclo! Todo siempre se puede arreglar.

¡Y la programación siempre lleva más tiempo de lo esperado! Encontrarás enchufes. Primero, las reglas para celebrar reuniones no son del todo claras. Siempre resulta cuando se impone una solución digital en el mundo analógico. El mundo real puede llegar a un acuerdo con la ambigüedad y la inconsistencia, pero el mundo digital no puede. En respuesta a sus preguntas, el Comité del Partido Demócrata preparará aclaraciones. Esto te detendrá. El comité también puede cambiar las reglas en el último segundo. Esto hará que cambie la aplicación justo antes de la fecha límite. A continuación, tiene varios desarrolladores, lo que significa sobrecarga de coordinación. ¿Cada codificador está 100% versado en dispositivos móviles,y en el desarrollo del servidor? ¿Todos dominan React Native perfectamente? Js? ¿Mecanografiado? ¿Comunicaciones cliente-servidor? ¿Qué frameworks y bibliotecas elegiste? Cada "No" agrega tiempo al desarrollo para tener en cuenta la coordinación y la capacitación. ¿Están todos contentos con los marcos de prueba que utiliza? Es una broma. Qué pruebas hay ... Sí, al principio escribieron un par de pruebas, pero la aplicación cambió tan rápido que se eliminaron.

El tiempo no espera. Han expirado dos meses: llegas a la línea de meta con el último esfuerzo y liberas la versión final.

Basado en el modelo económico de un sitio web, terminar con prisa es bueno. Al final, la prisa no importa, ¡porque cruzaste la línea de meta! Todos los problemas pueden resolverse en unas pocas semanas y luego pasar al siguiente proyecto.

Pero el apuro se reflejó en la Asamblea Democrática de Iowa. En el transcurso del evento, las llamadas comenzaron a llegar con quejas sobre la aplicación. Resultados teóricamente imposibles o duplicados comenzaron a llegar. Pronto, los programadores divertidos publican imágenes del KDPV y dicen que el Congreso de Facciones en Iowa no debería haber ordenado una solicitud, y que solo se puede confiar en la votación con tecnología de papel.

recomendaciones


Este ensayo me ayudó personalmente a concluir: al planificar un proyecto, debe formalizar el costo de la modificación. Lo he hecho intuitivamente en el pasado, pero debería concretarse concretamente. Tal formalización ayuda a comprender qué tareas no pueden fallar en ningún caso. Es como si estuviera en mi robótica móvil: hay largos ciclos de implementación, y el daño por el mal funcionamiento podría salir de escala. Pasamos mucho tiempo desarrollando monitoreo y creando métodos confiables para suprimir y detener sistemas fuera de control. También he estado trabajando con servicios web para consumidores durante diez años, donde las consecuencias del fracaso son menores. Existe una mayor disposición a asumir deudas a corto plazo y avanzar con el riesgo de fallas temporales, especialmente cuando la reversión es barata y la pérdida de datos es poco probable. Por lo menos, los estímulos están presionando para tal comportamiento.Existen técnicas especiales en nuestra industria para prevenir tales problemas. Uno de ellos -investigación de fallas imaginarias (pre-mortem). Necesitas hacer esto más seguido.

El fracaso de Iowa tiene un resultado positivo. Algunos no relacionados con TI se dieron cuenta de que había errores en los programas. En los próximos años, los patrocinadores del desarrollo de solicitudes para partidos políticos comenzarán a preguntar: "¿Qué garantiza que la situación con el Congreso de fracciones en Iowa no se repita?" Quizás se familiaricen con la literatura, que trata de enseñar a los gerentes cómo trabajar adecuadamente con los ingenieros. Por ejemplo, el Departamento de Defensa de EE. UU. Tiene una guía llamada "Cómo reconocer proyectos falsos ágiles", que describe signos sospechosos sobre un contrato. Los foros para startups están llenos de no expertos en tecnología que piden (y obtienen) consejos sobre la contratación de desarrolladores.

La industria de TI no ha aprendido nada. El Congreso de la Facción de Iowa brindó la oportunidad de examinar cómo la suposición de un "alto costo de error" cambiará nuestros procesos centrales. Pero no aprovechamos esta oportunidad y no extrajimos nada de ella. La industria del software de consumo no presta atención a los riesgos de errores. De hecho, incluso estamos contentos con los errores. Si el mundo exterior está interesado en mejorar la calidad de nuestro código en ciertas áreas, entonces deberían regular estas áreas. Esta no será la primera vez. Ley Sarbanes - Oxley e HIPAA son ejemplos de regulación en el desarrollo de un modelo económico de un sitio web. La regulación no es suficiente, pero puede resultar necesaria.

Esto es lo que queremos decir cuando decimos: "No sé cómo expresarlo, pero toda nuestra área es mala en lo que hacemos, y si confías en nosotros, todos morirán". Nuestra industria se formó en un entorno donde los contratiempos son baratos. Y estamos interesados ​​en un progreso rápido. Si la alteración es imposible o demasiado costosa, entonces nuestros procesos habituales funcionan mal.

More articles:


All Articles