No eres Google (You Are Not Google)
(blog.bradfieldcs.com)Muchos ingenieros de software no son racionales al elegir tecnologías. Al adoptar una nueva tecnología, a menudo la siguen simplemente porque la usan grandes empresas tecnológicas como Google o Amazon, sin una necesidad real ni una definición clara del problema. Por ejemplo, MapReduce y Hadoop nacieron para el procesamiento de datos a gran escala, pero cuando empresas que en realidad no manejan ese volumen de datos los implementan, terminan sufriendo costos de I/O innecesarios y pérdida de funcionalidades. Esto es simplemente un fenómeno de "culto a la tecnología (cargo cult)".
El texto propone una lista de verificación llamada UNPHAT para evitar esta imitación acrítica:
Understand – comprende bien el problema.
eNumerate – enumera distintas opciones.
Paper – lee los papers o libros blancos en los que se basa la tecnología.
Historical context – revisa el contexto histórico en el que fue desarrollada.
Advantages – compara ventajas y desventajas de forma equilibrada.
Think – piensa por tu cuenta si esta tecnología realmente encaja con el problema.
El texto presenta ejemplos de tecnologías como Cassandra, Kafka y SOA (Service-Oriented Architecture) que fueron adoptadas sin espíritu crítico en situaciones que no correspondían con sus casos de uso reales. Por ejemplo, Kafka fue creado para LinkedIn, que procesa millones de mensajes por segundo, pero a veces se usa en empresas pequeñas que apenas tienen unas decenas de transacciones al día.
El autor también subraya que incluso Google dejó de usar MapReduce cuando concluyó que ya no era la opción adecuada. Al final, lo importante no es la tecnología en sí, sino entender con precisión cuál es el problema que quieres resolver y elegir la tecnología que mejor se ajuste a ese problema.
Por último, el autor menciona que Pólya, Hamming y Rich Hickey también han repetido el mismo mensaje, y que la idea central es simple:
“Piensa. Y entiende el problema real.”
15 comentarios
Llegué aquí por casualidad porque apareció en las recomendaciones de Google, pero este artículo está escrito demasiado desde una perspectiva geek. Desde una perspectiva de negocio, no es una historia correcta en absoluto. ¿Por qué?
Es fácil encontrar especialistas en las herramientas grandes que usa Big Tech.
Mucha gente las aprende para entrar a Big Tech, y también hay mucha gente que se pone a estudiarlas porque Big Tech las eligió. Naturalmente, es fácil encontrar personas que sepan de esto, y también resulta sencillo conseguir gente con experiencia o especialistas. Pero, ¿qué pasa si es una herramienta que nadie conoce? No es que no exista gente que la haya estudiado a fondo, pero encontrar a esas personas será mucho más difícil que encontrar especialistas en herramientas de Big Tech.
Las herramientas grandes que usa Big Tech tienen abundantes referencias y documentación
Las herramientas grandes que usa mucha gente tienen abundante material para resolver problemas y muchos resultados en Google. En la mayoría de los casos, los problemas son cosas que otros también ya han vivido, y con una búsqueda simple se puede identificar el problema fácilmente. Pero en una herramienta desconocida es difícil encontrar referencias, y si surge un problema, es muy probable que se consuma bastante tiempo en identificar la causa. Y todo eso cuesta dinero. ¿Ese problema será realmente de la herramienta pequeña recién adoptada? ¿O estaremos malinterpretando un problema que viene de otro lado?
De hecho, para Big Tech es más fácil hacer este tipo de cambios. Como manejan volúmenes de datos enormes, una pequeña ganancia de I/O puede convertirse en un beneficio grande. Y además, hay mucha gente que decide estudiarlo solo porque Big Tech lo adoptó. Pero en las empresas medianas y pequeñas, debido a que el volumen de datos es relativamente menor, una pequeña ganancia de I/O no representa un beneficio tan grande, mientras que los problemas mencionados arriba sí son muy serios. Además, también hay menos gente dispuesta a aprender una solución adoptada por empresas medianas o pequeñas. Por eso, para una empresa mediana o pequeña, muchas veces la conclusión termina siendo que, en lugar de ponerse a evaluar estas cosas como un geek, resulta más económico simplemente seguir las herramientas de Big Tech.
Al leer el original, veo que es un texto escrito en 2017.
Han pasado 8 años desde entonces, y sorprende que esto siga aplicando.
¡Estoy muy de acuerdo con lo de arriba!
Solo que también creo que, cuando ocurre sobreingeniería en empresas pequeñas, a veces es porque quienes apuntan a grandes empresas quieren acumular experiencia con esas herramientas en compañías pequeñas.
Claro, aunque al CEO no le suele gustar mucho jaja
¿No será que el 80% de la razón por la que hasta las empresas pequeñas terminan usando tal cual herramientas diseñadas para las necesidades de las grandes corporaciones es esto? Quien debería controlarlo sería el CTO, pero a veces hasta el propio CTO está pensando en cambiarse a una gran empresa.
Cuando no hay mucho por hacer, uno termina haciendo cosas inútiles jaja.
Hasta los problemas fáciles hay que resolverlos de forma difícil para poder presumir que uno hizo algo. Y si lo haces fácil, también hay mucha gente que cree que entonces era fácil... jajajaja
A veces, por miedo a que sea difícil arreglar después algo hecho en pequeño y convertirlo en grande, se termina construyendo grande desde el principio...
Creo que es un texto que también aplica a K8s. Me hizo pensar en el libro "Cómo programar de forma que sea difícil de mantener". Jaja
Al final, hay que entender el problema que estas tecnologías intentan resolver y el contexto en el que surgieron. Algunos ejemplos que aparecen en el artículo son los siguientes.
Creo que hay que revisar muy bien si el problema que esas tecnologías buscan resolver y el problema que yo intento resolver están alineados.
Oh, me identifico. Me hizo recordar que, cuando daba mentoría a universitarios y perfiles junior, solía aconsejarles que intentaran entender la historia de la tecnología.
Parece que hay mucha gente que a veces olvida que la tecnología es una herramienta, no un objetivo.
En cuanto cosas como “ya fue validado por las grandes tecnológicas” o “se usa mucho últimamente” se vuelven criterios principales para elegir tecnología, el aumento innecesario de costos termina llegando de forma natural.
En Corea, el cargo cult de Spring es bastante fuerte.
Como es fácil conseguir personal en primavera...
En Corea, Spring no es tanto una cuestión de veneración...
Es más bien un híbrido entre la incompetencia del gobierno y la pereza de los desarrolladores.
Coincido muchísimo. Al final, Spring también será una herramienta para resolver problemas.
Lluvia de ideas, mapas mentales, deep learning, el tiempo de investigación se reduce; en el largo plazo, eso tiene efecto.