Podría construir esto durante el fin de semana.

¿Cuántas veces has oído eso (o incluso lo has dicho en voz baja)? Sé que lo he escuchado en conversaciones. También sé que me he preguntado lo mismo acerca de uno o dos productos. Oye, la idea aquí es súper simple: reunamos a un par de amigos y hagamos lo mismo, ¡solo que mejor!

Me gusta la opinión de João aquí. Nos recuerda que el caso de uso principal de una aplicación o SaaS suele ser tan fácil como parece. Pero es la falta de “pensamiento de segundo orden” lo que impide comprender las complejidades detrás de escena:

• ¿El equipo carecía de personal y se vio obligado a hacer concesiones?
• ¿Se gestionó el proyecto en cascada, lo que impidió que algunas ideas llegaran al lanzamiento?
• ¿Hubo una limitación de tiempo que influyó en la dirección del proyecto?
• ¿Simplemente no había presupuesto para cubrir una característica específica?
• ¿Hubo discordia en el equipo?

Hay tantas cosas que no vemos detrás del producto. João expresa esto claramente cuando explica por qué una empresa como Uber necesita cientos de desarrolladores de aplicaciones móviles. No están ahí para respaldar el caso de uso inicial; están encargados de resolver factores de segundo orden y, con suerte, de una manera que mantenga la complejidad al mínimo mientras escala con el resto del sistema.

El mundo está desordenado. Como el software es más ubicuo, estamos codificando este caos en 1 y 0. Es más que eso. Algunos escenarios son más difíciles de codificar en software que sus contrapartes predigitales. Una cola física de taxis en el aeropuerto es bastante sencilla de entender. No hay tecnología GPS involucrada, ni geocercas. Una persona y un coche sólo pueden estar en un lugar a la vez. En el mundo digital, las cosas se vuelven más complicadas.

Recuerdo una publicación que Chris escribió hace un tiempo donde insiste en una solicitud de función de Twitter aparentemente simple :

¿Por qué no puedo editar mis tweets? Twitter debería permitir eso.

Es el mismo trato. Las características son complicadas. Los productos son complicados. Sí, sería fantástico si esta aplicación tuviera una característica particular o usara algún marco ingenioso para acelerar las cosas, pero siempre hay que tener en cuenta el contexto y el pensamiento de segundo orden antes de pasar directamente al modo de solución. De nuevo, João lo dice mucho mejor de lo que yo puedo:

Es fácil simplificar demasiado los problemas y probar tecnologías nuevas y más eficientes que se optimicen para nuestros casos de uso. Sin embargo, al escalarlo al resto de la organización, empezamos a ver los dragones. Personas que no construyeron su software de la manera correcta . Pilas de tecnología enteras dependiendo de bibliotecas que los equipos no pueden actualizar por motivos™ . Rápidamente empezamos a darnos cuenta de que nuestra forma eficiente de hacer las cosas puede no servir para la mayoría de las situaciones.

Al menos hablando por mí, es tentador saltar directamente a una solución o a alguna conclusión. Somos solucionadores de problemas, ¿verdad? ¡Para eso nos pagan! Pero ahí es donde aparecen los dragones que describe João. Siempre hay más en la pregunta (y en la respuesta). A menos que matemos a esos dragones, corremos el riesgo de hacer suposiciones falsas y, en última instancia, respuestas incorrectas a cosas aparentemente simples.

Como siempre, los desarrolladores front-end lo saben . Eso incluye ser consciente de consideraciones de segundo orden.