Ley de Murphy y otras cinco leyes

Ley de Murphy "Todo lo que puede salir mal, saldrá mal". Esta ley proviene de la respuesta de Edward Murphy, un ingeniero aeroespacial a una prueba fallida de un cohete a principios de la década de 1950. La inspiración que nos da esta ley es utilizar siempre un diseño defensivo en partes clave del sistema, ¡porque algo en el sistema siempre saldrá mal! Esta ley se introduce fácilmente en el campo de la ingeniería de software. Cuando expone su software a los usuarios finales, estos escribirán creativamente cosas inesperadas y bloquearán el sistema. Por lo tanto, debe hacer que su software sea lo suficientemente robusto como para detectar y advertir sobre comportamientos inesperados. Cuando ejecuta software en una máquina, los problemas pueden ocurrir en cualquier lugar: desde el sistema en el disco duro hasta la fuente de alimentación en el centro de datos. Por lo tanto, debe asegurarse de diseñar su arquitectura para manejar fallas en todos los niveles. He tenido la oportunidad de experimentar la Ley de Murphy varias veces. Por ejemplo, una vez usé la cadena "null" para representar valores nulos en un marco de procesamiento por lotes. No pensé que hubiera un problema hasta que un usuario llamado "Null" envió una orden comercial y nuestro informe El proceso se interrumpió. por unas horas en otro momento, en otro proyecto. Cuando todo estaba listo para implementarse en producción, de repente una falla en la infraestructura de Azure provocó que el servidor en el que estábamos ejecutando los scripts de automatización fallara. Las lecciones del mundo real me han recordado lo difícil que puede ser la vida: “Todo lo que puede salir mal, saldrá mal”. Por lo tanto, tenga en cuenta la ley de Murphy y diseñe un software sólido.

Ley de Knuth "En (al menos la mayoría) de la programación, la optimización prematura es la raíz de todos los males." Esta ley es también una de las citas clásicas de Donald Knuth, que nos advierte que no optimicemos prematuramente el código hasta que se complete el proceso. debe optimizarse. De hecho, un código fuente simple y fácil de leer puede satisfacer el 99% de las necesidades de rendimiento y mejorar la capacidad de mantenimiento de la aplicación.

El uso de soluciones simples inicialmente también hace que sea más fácil iterar y mejorar cuando surjan problemas de rendimiento más adelante. En los lenguajes de programación con recolección de basura, la concatenación de cadenas suele ser un ejemplo de optimización prematura. En Java o C#, los objetos String son inmutables y aprendemos a usar otras estructuras para crear cadenas dinámicamente, como StringBuilder. Pero, de hecho, hasta que analice toda la aplicación, no sabrá cuántas veces se crea el objeto String y cuánto impacto tiene en el rendimiento. Por lo tanto, a menudo tiene más sentido escribir primero el código más limpio posible y luego optimizarlo cuando sea necesario. Sin embargo, esta regla no debería impedirle aprender las ventajas y desventajas del rendimiento y las estructuras de datos correctas de los lenguajes de programación. Y, como ocurre con todos los demás problemas de rendimiento, es necesario medir los gastos generales antes de optimizar.

La Ley de North "Cada decisión es una compensación" Bueno, admito que esto está tomado del discurso de Dan North Decisions, Decisions. Aún no es una ley reconocida. Pero esta cita afecta cada decisión que tomo, así que la incluyo aquí. En el día a día de los desarrolladores, tomamos innumerables decisiones, grandes y pequeñas, cada día. Desde nombrar variables hasta automatizar tareas (manuales) y definir la arquitectura de la plataforma.

Esta cita enfatiza que no importa qué elección hagas, siempre renunciarás a una o más opciones pero eso no es lo más importante. Lo más importante es tomar tu decisión sabiamente, entender las otras opciones y tener claro por qué no las eliges. Siempre debe sopesar y tomar decisiones basándose en la información que tiene actualmente a su disposición. Pero si luego aprende nueva información y descubre que su decisión anterior fue incorrecta, está bien. La clave es recordar por qué tomó esa decisión, reevaluar nuevas opciones y luego tomar una decisión nueva y racional. Repita "Cada decisión es una compensación". Entonces, haga su elección y sea consciente de todas sus opciones.

Ley de Conway "La arquitectura del diseño del sistema está limitada por el diseño de producción y refleja la arquitectura de comunicación de la organización de la empresa". En la década de 1960, un ingeniero llamado Melvin Conway notó que la estructura organizativa de la empresa afectaba la sistemas que desarrollaron. Describió esta idea en un artículo y la llamó "Ley de Conway".

Esta ley se aplica muy bien al campo del desarrollo de software, incluso hasta el nivel del código. La estructura organizativa de los equipos individuales que entregan componentes de software afecta directamente el diseño de los componentes.

Por ejemplo, un equipo centralizado de desarrolladores desarrollará una aplicación monolítica en la que cada componente está acoplado. Por otro lado, los equipos distribuidos desarrollan (micro)servicios individuales, con las preocupaciones de cada parte claramente separadas. Ninguno de estos diseños es bueno o malo, pero todos están influenciados por la forma en que se comunica su equipo. Hay muchos proyectos de código abierto de desarrolladores independientes de todo el mundo, a menudo bibliotecas modulares y reutilizables, que son un ejemplo revelador. Hoy en día, se ha convertido en una tendencia desacoplar grandes aplicaciones integradas en microservicios. Esto es genial porque acelera la entrega de proyectos. Pero también debe tener en cuenta la Ley de Conway e invertir tanto trabajo en desarrollar la organización de su empresa como en el desarrollo de su tecnología.

La Ley de la Trivialidad (Ley de la Trivialidad de Parkinson) "Los miembros de una organización dedican mucha energía a cosas triviales". Esta ley sostiene que el tiempo dedicado a las reuniones es inversamente proporcional al valor de la cosa. Es cierto que las personas prefieren centrar su atención y opiniones en cosas que conocen más que en temas complejos. Parkinson dio un ejemplo de una reunión en la que los miembros discutieron dos cosas: construir un reactor nuclear para la empresa y construir garajes para los empleados. Construir un reactor es una tarea enorme y compleja, y nadie puede controlar completamente la situación general. Confiaron plenamente en los expertos en procesos y sistemas y rápidamente aceptaron el proyecto.

Por otro lado, construir una cochera es algo que todo el mundo puede hacer, y cada uno puede tener una opinión sobre el color. De hecho, todos los miembros de la reunión expresaron su opinión, por lo que la decisión de construir la cochera llevó mucho más tiempo que la decisión de construir el reactor. Esta ley es tan conocida en la industria del software que más tarde se conoció como el efecto cochera. Por ejemplo, los desarrolladores dedicarán más tiempo a discutir la sangría correcta o la denominación de funciones que a discutir las responsabilidades de las clases o la arquitectura de la aplicación. Esto se debe a que todos pueden reconocer algunos cambios de carácter, pero los cambios en la estructura del proyecto requieren una carga cognitiva enorme. Otro ejemplo del efecto de cochera que puedes notar son las presentaciones de Scrum.

No me malinterpretes, me encantan las demostraciones y creo que es una gran oportunidad para estar frente a los usuarios y obtener comentarios sobre la aplicación. Pero a menudo las discusiones durante las presentaciones de Scrum giran en torno a cuestiones triviales en lugar de mirar el panorama general. Estas discusiones también son importantes, pero se debe tener cuidado de sopesarlas con las cuestiones más importantes y complejas. Una vez que comprenda este patrón, notará este comportamiento en las reuniones e interacciones. No le estoy diciendo que evite problemas “pequeños” en cada discusión; aumentar su conciencia puede ayudarlo a concentrarse en los problemas reales y prepararlo para estas reuniones.