Aprenda de los ingenieros de software y descubra el placer de pensar que «peor es mejor»
Recientemente tuve la oportunidad de hablar con varios ingenieros y arquitectos de datos sobre los problemas que enfrentan con los datos en sus negocios. Los principales aspectos negativos que escuché una y otra vez fueron:
- Sin saber por qué algo se rompió
- Dejarse engañar por los altos costos de la computación en la nube
- Se necesita demasiado tiempo para crear soluciones de datos o completar proyectos de datos.
- Necesita experiencia en muchas herramientas y tecnologías.
Estos problemas no son nuevos. Yo los he conocido, probablemente tú los hayas conocido. Sin embargo, no logramos encontrar una solución que resuelva todos estos problemas a largo plazo. Podría decir: «El primer punto se puede resolver con {insertar herramienta de observabilidad de datos}» o «El segundo punto simplemente requiere la implementación de un plan de gobierno de datos más estricto». El problema con este tipo de soluciones es que añaden capas adicionales de complejidad, lo que hace que los dos últimos puntos débiles se vuelvan más graves. La suma global de los problemas sigue siendo la misma, sólo la distribución entre los cuatro puntos es diferente.
Este artículo tiene como objetivo presentar un estilo opuesto de resolución de problemas: la simplicidad radical.
TL;DR
- Los ingenieros de software han logrado un éxito considerable al adoptar la simplicidad.
- El exceso de ingeniería y la búsqueda de la perfección pueden dar como resultado sistemas de datos inflados y de lento desarrollo, con costos exorbitantes para el negocio.
- Los equipos de datos deberían considerar sacrificar algunas funciones en aras de la simplicidad y la velocidad.
Una lección de estos informáticos
En 1989, el informático Richard P. Gabriel escribió un ensayo relativamente famoso sobre sistemas informáticos titulado paradójicamente «Lo peor es lo mejor». No entraré en detalles, puedes leer el ensayo. aquí por así decirlo, pero el mensaje subyacente era que la calidad del software no necesariamente mejora a medida que aumentan las funciones. En otras palabras, puede sacrificar la integridad por la simplicidad y terminar con un producto inherentemente «mejor» gracias a ello.
Era una idea extraña para los pioneros de la informática de los años cincuenta y sesenta. La filosofía de la época era: un sistema informático debe ser puro, y sólo puede serlo si tiene en cuenta todos los escenarios posibles. Probablemente esto se debió a que la mayoría de los principales científicos informáticos de la época eran académicos deseosos de tratar la informática como una ciencia dura.
Los académicos del MIT, la institución líder en informática en ese momento, comenzaron a trabajar en el sistema operativo para la próxima generación de computadoras, llamado multicsDespués de casi una década de desarrollo y millones de dólares de inversión, los ingenieros del MIT lanzaron su nuevo sistema. Era fácilmente el sistema operativo más avanzado de la época, pero la instalación era difícil debido a los requisitos informáticos y las actualizaciones de funciones eran lentas debido al tamaño del código base. Como resultado, nunca fue adoptado más allá de unas pocas universidades e industrias seleccionadas.
Durante la construcción de Multics, un pequeño grupo que apoyaba el desarrollo de Multics se sintió frustrado por los crecientes requisitos requeridos para el sistema. Finalmente decidieron retirarse del proyecto. A partir de esta experiencia decidieron crear su propio sistema operativo, con un cambio fundamental de filosofía:
El diseño debe ser sencillo, tanto en términos de implementación como de interfaz. Es más importante que la implementación sea simple que la interfaz. La simplicidad es la consideración más importante en un diseño.
—Richard P. Gabriel
Cinco años después del lanzamiento de Multics, el grupo disidente lanzó su sistema operativo, UnixPoco a poco fue ganando impulso y en la década de 1990 Unix se convirtió en la opción preferida para las computadoras, con más del 90% de las 500 supercomputadoras más rápidas del mundo Hasta el día de hoy, Unix sigue siendo ampliamente utilizado, particularmente como sistema subyacente para macOS.
Obviamente, además de su simplicidad, hubo otros factores que llevaron al éxito de Unix. Pero su diseño liviano fue, y sigue siendo, un activo muy valioso del sistema. Esto sólo pudo suceder porque los diseñadores estaban dispuestos a sacrificar la funcionalidad. La industria de los datos no debería tener miedo de pensar de la misma manera.
Volver a los datos en el siglo XXI
Mirando hacia atrás en mis propias experiencias, la filosofía de la mayoría de los proyectos de ingeniería de Big Data en los que trabajé era similar a la de Multics. Por ejemplo, había un proyecto en el que necesitábamos automatizar la estandarización de los datos sin procesar provenientes de todos nuestros clientes. Se tomó la decisión de hacer esto en el almacén de datos a través de dbt, ya que entonces podríamos tener una vista completa del linaje de datos desde los archivos sin procesar hasta la versión estandarizada de tabla única y más. El problema fue que el primer paso de la transformación fue muy manual, requirió cargar cada archivo de cliente sin procesar individual en el almacén y luego dbt creó una plantilla para limpiar el archivo de cada cliente. Esto llevó a la generación de cientos de modelos dbt, todos utilizando esencialmente la misma lógica. Dbt creció tanto que el gráfico de linaje de datos tardó unos minutos en cargarse en el sitio web de documentación de dbt y en nuestras GitHub Actions para CI (Integración continua) tardó más de una hora en completar cada solicitud de extracción.
Esto podría haberse resuelto de manera bastante simple si la administración nos hubiera permitido realizar la primera capa de transformaciones fuera del almacén de datos, utilizando AWS Lambda y Python. Pero no, eso habría significado que la línea de datos producida por dbt no estaría completa al 100%. Es todo. Esta fue la razón principal por la que el proyecto no debería simplificarse enormemente. Al igual que el grupo que se separó del proyecto Multics, dejé este proyecto a mitad de construcción, era demasiado frustrante trabajar en algo que podría haber sido mucho más simple. Mientras escribo esto, descubrí que todavía están trabajando en el proyecto.
Entonces, ¿qué es la simplicidad radical?
La simplicidad radical en la ingeniería de datos no es un marco o un conjunto de herramientas de pila de datos, es simplemente una forma de pensar. Una filosofía que favorece soluciones simples y directas a sistemas complejos y globales.
Los principios clave de esta filosofía incluyen:
- Minimalismo: centrarse en las características principales que proporcionan el mayor valor, en lugar de intentar cumplir con todos los escenarios o requisitos posibles.
- Compromiso: sacrificar intencionalmente un cierto grado de integridad o perfección en aras de la simplicidad, la velocidad y la facilidad de mantenimiento.
- Pragmatismo sobre idealismo: favorecer soluciones prácticas y alcanzables que resuelvan eficazmente problemas empresariales del mundo real, en lugar de buscar sistemas teóricamente perfectos pero demasiado complejos.
- Carga cognitiva reducida: diseñe sistemas y procesos que sean más fáciles de entender, implementar y mantener, reduciendo la experiencia requerida en múltiples herramientas y tecnologías.
- Rentable: adoptar soluciones más simples que a menudo requieren menos recursos de TI y capital humano, lo que resulta en costos generales más bajos.
- Agilidad y adaptabilidad: cree sistemas que sean más fáciles de modificar y escalar según las necesidades del negocio, en lugar de soluciones rígidas y demasiado sofisticadas.
- Centrarse en los resultados: centrarse en los resultados finales y el valor empresarial en lugar de perderse en las complejidades de los propios procesos de datos.
Esta mentalidad puede estar en contradicción directa con las soluciones modernas de ingeniería de datos que implican agregar más herramientas, procesos y capas. Por lo tanto, se debe esperar que usted defienda su posición. Antes de sugerir una solución alternativa y más sencilla, prepárese con un conocimiento profundo del problema en cuestión. Recuerdo la cita:
Se necesita mucho trabajo para crear algo simple, comprender verdaderamente los desafíos subyacentes y encontrar soluciones elegantes. […] No se trata sólo de minimalismo o falta de desorden. Se trata de profundizar en las profundidades de la complejidad. Para ser realmente sencillo hay que llegar muy lejos. […] Hay que entender profundamente la esencia de un producto para poder deshacerse de las partes que no son esenciales.
—Steve Jobs
Nota al margen: tenga en cuenta que adoptar una simplicidad radical no significa ignorar nuevas herramientas y tecnologías avanzadas. De hecho, una de mis soluciones favoritas para un almacén de datos en este momento es utilizar una nueva base de datos de código abierto llamada patoDB. Compruébalo, es genial.
Conclusión
Las lecciones aprendidas de la historia de la ingeniería de software brindan información valiosa para el panorama de datos actual. Al adoptar una simplicidad radical, los equipos de datos pueden resolver muchos de los problemas que enfrentan las soluciones de datos modernas.
No tema defender la simplicidad radical dentro de su equipo de datos. Sea el catalizador del cambio si ve oportunidades de racionalización y simplificación. El camino hacia la simplicidad no es fácil, pero las recompensas potenciales pueden ser sustanciales.
