La visión de las cosas del programador
Es difícil para los no programadores, entender cuán complejo puede ser el desarrollo de software. Sólo tienes que decirle al al ordenador qué hacer, ¿verdad? ¿Qué tan difícil es eso?
Bueno, es engañosamente difícil, porque el ordenador carece completamente de lo que los teóricos han descrito como un marco de conocimiento. Por ejemplo, puedo pedirle que haga algo simple, como “tráeme un bocadillo de jamón”. Puedes intuir rápidamente que yo en realidad lo que quiero decir es “vete a la cocina, haz un bocadillo de jamón, y tráemelo” o “vete a la bocatería, pídeme un sándwich de jamón, y me lo traes” basado en el contexto en el que físicamente estamos y lo que ha sucedido las últimas veces que esa misma petición se ha realizado.
Se puede intuir, en el caso del escenario de ir a la cocina, que hay que ir a la nevera, encontrar el jamón, el queso cheddar blanco (porque sabes que me gusta, y no el americano), la mostaza Djion (porque sabes que me gusta en el bocadillo de jamón y no la mayonesa) , encontrar una barra de pan, montar todo el asunto, guardar los ingredientes de nuevo en la nevera, averiguar dónde están los platos, emplatarlo, y traerlo. Y si eres muy observador, notarás que me estoy saltando un mogollón de pasos como saber cuánta mostaza a utilizar, sacarle la envoltura plástica al queso, cuánto jamón entra en un bocadillo estándar de jamón, qué es en realidad un bocadillo, y si nos ponemos qué es el “jamón”…
Cuando te sientas a programar no te puedes saltar ni uno de esos pasos minúsculos. Si no se especifican detalladamente los pequeños pasos aparentemente microscópicos que son intuitivamente obvios para ti, como ser humano, que vives en un mundo lleno de contextos y matices, el ordenador hace lo incorrecto, o falla, o a veces las dos cosas.
Un poco de empatía a la hora de hacer peticiones
Como no programador, probablemente le estés diciendo a los programadores que están trabajando en un software cosas del estilo: “¿puedes hacer que esa ventana sea más grande?” o “dirigirte al usuario por su nombre de pila” o “deja que el usuario publique eso en su página de Facebook” o cosas vagas e indeterminadas del estilo, en un contexto de una gran variedad de cosas de las que el ordenador “no sabe” absolutamente nada.
Para ti es intuitivo, y parece muy fácil…. entonces, ¿Cuál es el problema?
El problema está en que los programadores con este tipo de tareas tienen que manejar diferentes capas de complejidad. Hoy en día, hay que dar por hecho que no han escrito todo el código con el que trabajan ellos mismos, han usado una librería (trozos de código escrito por otra persona para solucionar problemas muy comunes) proporcionada por un tercero, para hacer todo el trabajo “gordo”. Normalmente esto implica usar más de una librería, ya que hay muchos tipos de dependencias e interdependencias.
Así que cuando le dices a un desarrollador: “deja que los usuarios posteen en Facebook”, tienes que tener en cuenta que van a esccuchar tu pertición y van a pensar “eh, claro, eso se puede hacer más o menos de forma sencilla quizás, creo que tenemos su información de Facebook en una base de datos por aquí, creo que tenemos las librerías apropiadas para eso aquí, sí, se puede hacer fácilmente”, lo que conduce a hacer una estimación optimista de cuanto tiempo puede tomar.
Empiezan los problemas imprevistos
Pero cuando se ponen a hacer la tarea en cuestión, los desarrolladores caen en la cuenta de que uno o más de los supuestos que habían pensado estaban equivocados, o que para usar la librería que querían usar implica que no pueden usar la versión de una librería que están usando ahora, y tienen que usar una nueva librería distinta de la versión actual, lo que implica volver a programar todo el código que hace uso de esa librería (nada de esto tiene que ver con el trabajo que tú habías solicitado, si te fijas) y luego ponerse con la tarea encomendada, para luego darse cuenta de que algo que pensaban que podían usar ahora se ha quedado obsoleto y ahora necesitan encontrar otra librería que luego tienen que volver a valorar para ver si es compatible con el código que tienen montado ahora…
Todo este proceso se va haciendo cada vez más complejo en el momento en que un supuesto mal asentado de base resulta ser equivocado. Al principio todos los supuestos parecen tener lógica y aparentemente están bien planteados, pero cuando te metes a programar es cuando puedes aseverar al 100% que todo va a salir según lo previsto.
La técnica del descargo de la responsabilidad
Los mejores programadores con los que he trabajado empiezan a establecer sus previsiones y estimaciones de tiempo de trabajo en torno a fórmulas de descargo de responsabilidad del tipo: “si damos por cierto X, entonces…” 0 “si algo no funciona como está documentado…” y cosas parecidas. Saben, por experiencia, que siempre hay algo escondido, al acecho, en las profundidades como un oso polar que sorprende a la foca para devorarla. Y por ello preparan al cliente que les paga las aplicaciones en consecuencia, mentalizándolo de que estas cosas suelen pasar de forma inevitable.
Los programadores menos experimentados, llenos de confianza en si mismos tanto a la hora de programar, como a la hora de pensar que saben todo lo que tiene que hacerse y dando a entender que lo tienen todo bajo control, son menos cautos y caen en el “sí, claro, eso me toma una semana”. Pues aveces sí, tienen algo de presupuesto y pueden tapar los problemas que surgen de temas inesperados, pero muchas otras veces no, y se meten en un problemón con el cliente y con la empresa para la que trabajan.
Conclusión: hay que saber traducir lo que dice un programador
Conclusión, hay que saber traducir. Si un programador dice “eso no se puede hacer”, casi siempre lo que quiere decir es “ni de broma voy a poder hacer eso dado que mi forma de percibir intuitivamente las limitaciones operativas reales con las que me tengo que desenvolver en la empresa, y es tan difícil explicarte todo esto, que me va a explotar la cabeza. Vete. Lejos.”
Si eres el jefe de proyectos y recibes muchos “eso no se puede hacer”, es hora de volver a evaluar no solo tus expectativas, sino el entorno de trabajo en el que están los programadores a tu cargo. No hay suficientes, no tienen suficientes recursos, les estás exigiendo demasiado en cosas que no les permite avanzar en tareas fundamentales -algo está fallando…
En vez de poner cara de frustración e incredulidad, enfoca el asunto con un “Vale, ¿y que podemos hacer para que esto sea posible de hacer?”. Llegarás mucho más lejos, y con un poco de suerte podrás corregir la deriva de un barco que va hacia el naufragio.