El hecho de que sean interesantes de resolver no significa que alguien los necesite

"Un grupo de personas está haciendo una lluvia de ideas en una computadora portátil y una hoja de papel", foto de Stefan Stefanchik de Unspalsh

Hay muchos factores que conducen a la creación de software deficiente: la elección de herramientas, la comunicación del equipo, el desinterés personal de los desarrolladores en el éxito, la metodología de prueba. Me parece que todo esto tiene la causa principal: estos son problemas imaginarios.

El software excesivamente complejo o que no funciona no fue concebido como tal. Simplemente está diseñado para otra cosa, y no para una tarea real.

Suponga que publica podcasts y necesita un sitio web donde pueda vender productos relacionados, ganar dinero en publicidad y, lo más importante, publicar podcasts, videos y blogs.

Los requisitos para esta pequeña aplicación web podrían verse así:

• Descarga rápida para Norteamérica con transmisión de podcast en vivo
• Sin fallas en los primeros 15 minutos para el 99.99% de los usuarios, preferiblemente una falta total de fallas
• Buena integración con Google Adwords y posiblemente otros sistemas publicitarios de terceros si tiene tiempo
• Enlaces dinámicos a los últimos productos en la tienda y, si es posible, recomendaciones a los usuarios en función de las páginas visitadas.
• Integración con el reproductor de Facebook Live. Si puede crear fácilmente una solución de transmisión alternativa sin Facebook, aún mejor

Usted le da estas especificaciones al equipo del contratista y les habla un poco. Todo parece estar en la misma longitud de onda. Pero cuando muestran un prototipo en dos meses, su cara se llena de sangre. Usted gastó $ 15 mil en un pedazo de basura y desea recuperar su dinero.

Cuando abre por primera vez la aplicación se congela. Usted pregunta cómo elegir el tipo de pancartas, y le muestran una interfaz de usuario fea e incomprensible. ¡La mitad de los enlaces a los productos en la tienda están rotos o no hay imágenes, y la transmisión en vivo a través de Facebook se retrasa!

Pero el equipo de desarrollo no entiende tu ira. De hecho, desde su punto de vista, lograron hacer un trabajo infernalmente difícil.

Pusieron su alma en la creación de la aplicación, tiene características sorprendentes:

• El sistema de recomendación más avanzado.
• Algoritmo de descifrado de texto en tiempo real para todas las secuencias de audio
• La página de inicio se carga más rápido que 200 ms en todo el mundo
• El protocolo de transmisión y el cliente se realizan casi desde cero a menos que desee confiar en Facebook Live
• Se ha desarrollado un servicio que facilita la integración de más de 20 intercambios publicitarios.

El problema es que solicitó un producto básico con varias características adicionales, siempre que sean bastante simples de implementar. Y el equipo de desarrollo entendió de manera diferente. Escucharon algunas tareas emocionantes que hacer ... y muchas características básicas aburridas que no merecen mucha atención y pruebas rigurosas.

Peor aún, no se comunicó directamente con los desarrolladores: habló a través de un teléfono dañado. Usted habló con un vendedor que mantuvo reuniones con algunos gerentes de nivel medio. Escribieron algunas especificaciones comerciales para el gerente del proyecto, quien escribió las especificaciones técnicas, y se las dio al líder del equipo o al arquitecto, y él y su equipo comenzaron a desarrollar el producto. Cada enlace introdujo distorsión en el camino.


Los problemas imaginarios son a menudo más interesantes de resolver que los reales. Las personas con un exceso de inteligencia juegan juegos competitivos, inventan y resuelven problemas matemáticos y escriben libros para responder preguntas abstractas sobre la naturaleza humana, y todo esto es gratis, solo por diversión. Pero es probable que un programador mediocre le cobre una tarifa considerable por crear una aplicación de Android simple. Esto no se debe a que los programadores mediocres sean más difíciles de encontrar que los genios, sino a que las primeras actividades son interesantes y las últimas son bastante aburridas.

La mayoría de los programadores quieren que les paguen y divertirse al mismo tiempo. Por supuesto, la definición de "interesante" es diferente para todos, pero para muchos ingenieros se trata de resolver problemas interesantes y complejos que se encuentran en el campo de la solubilidad.

Dele a una persona inteligente demasiadas tareas aburridas que no se pueden automatizar, y terminará volviéndola loca. Sin embargo, el cerebro humano, después de miles de millones de años de evolución, se ha vuelto muy inventivo para mantener la razón. Así como las víctimas de privación o abuso infantil encuentran la salvación en los libros de ciencia ficción, las víctimas de la programación corporativa y los trabajadores independientes buscan la salvación para resolver problemas imaginarios.



La cantidad de problemas imaginarios que un ingeniero de software puede crear para sí mismo depende de su imaginación y de la complejidad de los problemas reales que deben resolverse.

Cabe señalar que este problema no es exclusivo de los desarrolladores. Los departamentos de administración, ventas, recursos humanos, soporte, legal e incluso contable, todos tienen sus propias formas únicas de crear problemas imaginarios. Algunos intentan entrar en el proceso de toma de decisiones cuando su presencia en la reunión es simplemente una formalidad o no se requiere en absoluto. Otros sobrestiman el problema menor asociado con su rol, o emplean muchos más empleados de los necesarios para demostrar su importancia.

Cuando los problemas son demasiado estúpidos, las personas inteligentes encontrarán la manera de rectificar la situación.


Pero los problemas imaginarios no solo provienen de desarrolladores aburridos. También resultan de largas cadenas de comunicaciones.

Cuando recién comencé a buscar clientes como freelance, no podía permitirme construir una comunicación a mi discreción. Así que tuve que lidiar con largos hilos de correo con cientos de cartas, donde se discutieron detalles menores del MVP interno. Las personas durante la semana cambiaron todos los requisitos del proyecto. Tuve clientes que hicieron tales preguntas: "¿Será compatible con el ICO?" o "¿Puedo agregar algo de IA aquí?"

Por supuesto, la mayoría de los clientes tienen suficiente experiencia, pero incluso ellos a menudo carecen de conocimiento para formular o construir algunos requisitos. Esto es normal, porque parte de mi trabajo como "técnico informático" es ayudar a las personas a comprender lo que están haciendo y lo que no necesitan, según su situación específica. Pero es mucho más difícil determinar cuándo hay varias juntas entre usted y el cliente.

Los requisitos cambian porque alguien entendió mal la intención o intentó hacer frente al aburrimiento antes mencionado

A la mayoría de las empresas les gusta comenzar un vendedor que molesta a los clientes potenciales, comercia y generalmente describe el producto. También hay especialistas con habilidades avanzadas de comunicación para discutir con el cliente especificaciones y requisitos más detallados: generalmente es la misma persona de ventas, solo un poco con un título de trabajo diferente. Y hay un sistema corporativo interno, varios niveles de gestión y, posiblemente, cierta jerarquía en el equipo técnico.

Cuando la lista de requisitos de un cliente pasa por tantas personas, incluso si estas personas tienen las mejores intenciones, algo inevitablemente se pierde en el proceso. Algunas veces esto sucede porque el requisito original no tenía sentido o necesita ser cambiado. Quizás el vendedor le dijo al cliente: "En solo 39,999, lo haremos en la cadena de bloques desde arriba". Estuvo de acuerdo, pero todos los demás tienen que adivinar lo que significa hacer en la cadena de bloques.

Muy a menudo, los requisitos cambian porque alguien entendió mal la intención o intentó hacer frente al aburrimiento antes mencionado, tratando de hacer que su trabajo o el trabajo de su equipo fuera más interesante e impresionante.

Detrás de todo esto, se pierden los requisitos iniciales: los problemas reales que deben resolverse. Se reemplazan por problemas y vacíos imaginarios, y hay muchas personas que están listas y dispuestas a llenar estos vacíos con sus problemas imaginarios, porque los problemas reales que necesitan resolver son aburridos, y llenar los vacíos les da satisfacción.

Complejidad excesiva y selección natural.

A menudo hay una razón más oscura para la aparición de problemas imaginarios: tales problemas ayudan a un equipo o empresa a crecer, incluso pueden convertirse en una parte integral de su trabajo.

"Las personas que son eliminadas, seleccionadas y alentadas a buscar soluciones complejas no tienen ningún incentivo para introducir soluciones simplificadas".
- Nassim Nicholas Taleb

¿Has oído hablar de esos tres programadores que han encontrado una solución verdaderamente simple para la banca web segura? Desarrollaron un software bancario perfecto desde cero utilizando una metodología de diseño funcional y lenguajes seguros, y luego comenzaron a transferir grandes bancos a su increíble infraestructura.

Puede que no hayas oído hablar de ellos, porque no existen. Pero hay muchos equipos de miles de desarrolladores que no pueden aprender conceptos simples, como "revertir a la versión anterior" , y están constantemente ocupados creando software bancario.

Almacenar y transmitir números no es un problema particularmente difícil. Indexar todo el contenido de Internet y mostrar el resultado correspondiente para una consulta en lenguaje natural en una fracción de segundo es otra cuestión. Pero solo unos pocos tipos inteligentes lograron resolver este problema.

El problema crónico de la banca en línea es que el ecosistema bancario realmente se ha destacado en su propia jerarquía de apropiación de dinero. Sus líderes son sanguijuelas corruptas que se adhieren al cuerpo de la sociedad, pero los líderes de la organización solo reflejan el estado de todo el sistema.

No digo que la mayoría de los empleados bancarios comunes sean personalidades viciosas y dañinas. En absoluto Como regla general, estos son tipos amigables que ganan dinero en alimentos, vivienda y educación para sus familias. Pero su principal incentivo no es arreglar el software bancario, sino ahorrar trabajo. Perder un trabajo en la economía moderna es un problema grave para algunas personas, y en la industria bancaria una palabra descuidada o una iniciativa excesiva es una manera fácil de comparecer ante un comité disciplinario.

Por lo tanto, los sistemas bancarios siguen siendo los mismos, no porque sean efectivos, sino por inercia. Esta inercia se manifiesta en la forma de resolver problemas imaginarios para evitar resolver problemas reales, cuya solución, como ya se señaló, amenaza el trabajo de otras personas. Resolver estos problemas reales puede llevar al despido o, en el caso de algunas "instituciones" particularmente desagradables como Goldman Sachs, a varias cartas que arruinan la vida del ex empleado y terminan con un extraño suicidio .

"¡Es difícil lograr que una persona entienda algo si su salario depende de lo que no entiende!"
- Upton Sinclair

Las corporaciones ordinarias ignoran el hecho de que la alta dirección pasa el 90% de su tiempo "reuniéndose con clientes", incluidos viajes a islas tropicales y millones de presupuestos para "gastos generales". A su vez, la alta gerencia hace la vista gorda ante la corrupción en las filas.

A medida que los gerentes de nivel medio fomentan sus fantasías de Wall Street estilo lobo, la alta gerencia hace la vista gorda ante el comportamiento de estos gerentes que compran oficinas excéntricas, contratan a tres secretarias y una docena de pasantes.

Como los gerentes comunes no se quejan de sus fantasías dictatoriales y su sed de poder, los gerentes de nivel medio hacen la vista gorda ante el hecho de que en lugar de reducir costos, pasan tiempo en la presentación de PowerPoint "Mejorando nuestra metodología ágil ágil".

Dado que los líderes de equipo no prestan atención a que sus jefes ni siquiera saben cómo usar Excel y van a la oficina un par de veces a la semana, los gerentes comunes hacen la vista gorda cuando los líderes de equipo y arquitectos hablan sobre "la próxima generación de interacción entre nuestros sistemas a través de JRPC y microservicios que usan Hibernate y Spring ”cuando estas malditas consultas MySQL se ejecutan durante más de un día.

Dado que los desarrolladores no parecen darse cuenta de que los líderes de su equipo no escriben ningún código que no sea diagramas, los líderes del equipo no se quejan de sus desarrolladores, quienes, en lugar de EXPLICAR los frenos de la solicitud anterior, rehacen la interfaz de usuario por décima vez en un año utilizando el nuevo marco de JavaScript.

Este es un círculo vicioso para resolver problemas imaginarios: desde el CEO que no entiende que robar otros 30 millones no le dará amor paternal, hasta el aprendiz que no entiende que el nuevo botón "Enviar" en Angular-Material-Bootstrap 19.13.5 no cambiará que las contraseñas se almacenan en texto plano (y se usan para verificar las cookies).

Pero todos tienen que continuar resolviendo problemas imaginarios, porque si dejan de hacerlo, comenzarán a enfocarse en problemas reales y comprenderán que todo el sistema está roto. Pueden entender que en la esquina de la oficina, Debra ha estado mirando los gráficos de tiempo de actividad del clúster de servidores durante diez años, aunque hace cinco años la compañía se mudó a AWS. Pueden entender que el 99% de sus tareas son necesarias solo para salvar el trabajo de otra persona. Y esta conciencia es difícil de aceptar, me atrevo a decir, es incluso imposible para la mayoría. Por lo tanto, la mayoría encuentra una manera de adaptarse.