[pl_video type="youtube" id="BKorP55Aqvg"]
En el mundo de la programación los desarrolladores de software tienen un gran problema, al final todo recae sobre ellos y me explico:
- Si un programador comete un error, pues lo corrige y ya está, lo normal.
- Si su jefe comete un error, al final lo tiene que arreglar el programador también.
- Si el cliente toma una decisión equivocada, ¿qué pasa? Estará el programador intentando arreglarlo a las 3 de la mañana.
Y así sucesivamente...Como consecuencia, los buenos programadores experimentados aprenden a "gestionar" con mentirijillas piadosas a todas las personas que le rodean para evitar que estos errores sucedan porque bien saben que los demás (mandos, clientes, etc.) no tendrán que pagar el precio de una planificación descuidada, una toma de decisiones errónea, etc...Y es por esto que los programadores "mienten", o al menos ocultan cositas, para evitar sobresaltos, sorpresas desagradables, experimentos y decisiones alocadas.[caption id="attachment_7010609100993" align="alignright" width="280"]
Mentira piadosa[/caption]Si lo piensas detenidamente esto suele suceder en aquellos sectores en los que hay marcados perfiles "técnicos" que tienen que interactuar con perfiles "no-técnicos". Dentro de estos campos puedo concluir que los programadores quizás mientan mucho menos que otros profesionales de perfil técnico.Quizás mientan menos -que no quiere decir que no lo hagan- por la mentalidad requerida para ser un buen programador:
- tienes que ser capaz de conservar el juicio mientras haces un montón de trabajo, y tener que estar pensando qué mentira le has contado a cada persona interfiere negativamente en ello.
- es demasiado fácil cazar a un programador esquivo ya que documentas tu trabajo ya sea vía email, comentarios en el código o viendo el control de fuentes...
De todos modos tenemos que admitir que de vez en cuando hay frases insinceras que los desarrolladores usan para escurrir el bulto y poder centrarse en el trabajo. A continuación recojo una compilación de las mentiras más comunes que dicen los programadores:
- Lo he programado de prisa y corriendo, pero lo arreglaré pronto.
- Esta tarea es facilísima. He terminado ya, casi.
- Si hay un bug, es imposible que esté mi código.
- Añadiré la prueba unitaria en la siguiente salida de versión.
- Ya comentaré y documentaré el código más tarde.
- ¿Esto? No. No es un bug, es una funcionalidad.
- Para la tarde estará terminado, está casi hecho ya.
- En mi máquina funciona.
- Está terminado al 90%.
- Estoy analizando los requisitos en profundidad. Empezaré a programar inminentemente.
- Esto es una solución temporal, pero no va a ir así en producción.
- Lo voy a añadir a mi TODO list.
- Esto debe ser un problema del navegador.
- Esto lo empiezo el lunes.
- Ya lo he terminado, ahora estoy en fase de pruebas.
- Esto es sencillo, me tomará una semana como mucho.
- Ayer lo dejé funcionando... !no tengo ni idea de por qué no funciona hoy!
- Esto lo arreglo yo. Cero preocupaciones.
- La culpa de esto es del usuario.
Hay mil variaciones posibles de esta mentirillas insignificantes, pero creo que se entienden bien. Y en esta linea podemos reproducir las típicas frases que requiere una interpretación cuando las pronuncia un programador:
- Frase: "Es solo un prototipo."
- Traducción: Ese código es el que va a ir en la versión final del proyecto salvo que se cuelgue tanto y nos veamos obligados a volver a escribirlo.
- Frase: "Esto queda hecho en tres días, como mucho."
- Traducción: Dos semanas.
- Frase: "Eso no se puede hacer, yo no lo veo."
- Traducción: Probablemente se pueda, y quizás no tome tanto tiempo, pero el programador en ese momento no sabe bien cómo hacerlo y prefiere no comprometerse si no tiene que hacerlo.
- Frase: "Claro, lo que tú veas."
- Traducción: Odio esta funcionalidad inútil que quieres implementar y que a penas va añadir nada al software.
- Frase: "Creemos que saldrá en el segundo trimestre."
- Traducción: cuarto trimestre.
Ahora, hablando en serio, muchas de las frases que he escrito aquí son más bien mentiras del sector. Muchos comerciales, gerentes, gestores y mandos en las empresas de software trasladan al cliente "funcionalidades" que aún no existen o incluso prototipos enteros haciéndolos pasar por programa final. Con el tiempo aprendemos a velar más por el largo plazo y a no trasladar lo que no existe aunque el software esté ya muy avanzado. El que esté libre de culpa que tire la primera piedra :)
