¿ Pro/dev ? hacker garage Guadalajara

Hoy fui a este evento llamado pro/dev  en hacker-garage y debo decir que salí muy incomodo del evento, si bien, no negare que la mayoría de los consejos son ciertos, me sorprende inmensamente que el presentador se atreva  a recomendar no optimizar el código si cumple con la funcionalidad… y por optimizar código no me refiero a esas mamadas pendejas de implementar  frameworks populares como metorjs, angular2  o reescribir todo el forntend  en “inserte aquí cualquier mamada que se les ocurra”.

No somos maquinas, somos humanos y cometemos errores, y si bien es cierto que el primer error es lanzarte a resolver el problema antes de saber cual es realmente el problema. también es cierto que la primer solución del problema (una vez lo tenemos definido) es probable sea poco optimizada y sucia. Y esto, para mi es lo que separa a un programador cualquiera de un buen programador. [codigo limpio]

Y antes de empezar a escribir código, coincido 100% con los amigos de pro/dev… tienes que escribir la especificación y esta tiene que ser validada. Pero incluso  en la definición de la especificación podemos ser realmente estúpidos.

 Mars Climate Orbiter es una nave de la NASA que se estrello contra la superficie marciana por que un laboratorio decidió usar centímetros y otro laboratorio decidió usar pulgadas. [nota de prensa]

Este mismo caso es completamente usual que ocurra con las fechas en un sistema, y es que a la empresa A se le ocurrió que la fecha fuera formato dd/mm/yyyy  y a la empresa B se le ocurrió usar  el formato  yyyy/mm/dd   y corregir el problema en la empresa A o B puede implicar toquetear 200 lineas en 143 archivos diferentes…

y si por un momento, el programador a mitad del desarrollo hubiera pensado… “umm, y si el formato de la fecha lo pongo en una constante en un archivo .config?” y  hubiera tenido la etica para corregir el problema no especificado en la especificación. (suponiendo que se percate de ello, y no diga.. “nah, yo cumplo con mi chamba de codear esta mierda”)

En otro caso, supongamos que la especificación de un problema dentro un sistema es  “pasar un valor por una función que divide, y el residuo tiene que pasar reiteradamente por esta función hasta que tienda a 0″…. (aclaremos el  problema)

Eres una empresa que vende velas, y recoge la cera no quemada para fabricar mas velas. cada 3 velas consumidas se genera una nueva vela… la pregunta es: si tengo 100 velas iniciales ¿cuantas velas en total venderé si recojo la cera de estas? (hasta que me sea imposible recoger mas cera)

Una tarea del desarrollo es hacer esta función, pero hay mas cosas por hacer dentro del sistema, por lo que se le destina 5 horas de desarrollo… Los programadores no somos sabios, y lo primero que haremos  seguramente es una función recursiva o un ciclo.  El tiempo que tarde esta función en resolver el problema va a ser exponencial (en realidad es logaritmica, pero no importa). si metemos un millón de velas, seguramente la función tardara unos segundos en responder.

Pasan las 5 horas, y te das cuenta que todos los valores al plasmarlos en una gráfica muestran un patrón que se traduce a una función generadora y encontrar esta función es una hora extra de trabajo que hará que sin importar el parámetro de entrada la operación siempre se resuelva en tiempo constante de “0”

Desde mi opinión si el tiempo de re-implementar una función es mínimo y genera una optimización sustancial. ¡Tiene que hacerse sin importar si “retrasa el proyecto”!. Si bien la empresa realmente nunca venderá un millón de velas, una función que consume recursos es un error, y un error mas otro error a lo largo de un desarrollo generar retrasos mas grandes y perdidas de dinero. ¿Cómo puede un proyecto acumular un retraso de un año?… acumulando retrasos errores día a día

Si no nos hacemos tiempo para solucionar un problema hoy, cuando tendremos tiempo para corregirlo.

¿que podría pasar si no lo corregimos?

bueno, podría no pasar absolutamente nada… O la empresa podría empezar a crecer a un ritmo no esperado, podría el programador original ya no estar, y podría el nuevo equipo decir “oh, si… esto se arregla comprando mas hardware… compren mas hardware!!!” si… el hardware es barato… ¿Y? es mas barato no comprar mas hardware… y solo costaba optimizar un cuello de botella.. no reescribir el kernel de linux.

(“._.)

¿a quien le corresponde tomar la decisión de corregirlo?

al “Project Manager” y/o al “Technical Leader”  pero en mi experiencia, en muchas empresas ninguno de los dos puestos existe y el “gerente” no tiene ni puta idea… entonces la decisión debe ser tomada por el programador silenciosamente. Al gerente no le importa, al menos tengamos el profesionalismo de hacernos pendejos un ratito mas para entregarlo bien en lugar de ignorar el problema hasta que explote.


Definir el problema antes de programar es la parte mas importante, si.. eso tiene que quedarle claro a cualquiera. Pero una vez definido el programador que aspira ser “pro-developer” tiene que tener la capacidad de ver mas lejos que la definición (dentro de lo humanamente posible).

y por ultimo… y de nuevo regreso a la ética de un programador y llamare a esto “el autobús escolar”: (que creo leí en Anti-patrones)

¿que pasa si a tu equipo de programadores estrellas salen a tomar una cerveza, pasa un autobús escolar y los mata a todos?

dejare la pregunta abierta por hoy.. por que da para un buen post…

 

PD: no mames… ¿ya pongo referencias bibliográficas? alguien mateme, odio en que me estoy convirtiendo.

Martin Quinta

Crecí con una computadora desde el kinder. Empece a programar a los 14 y hoy, mas de una década después… realmente odio estar frente a una computadora. Pero programar es en lo que soy bueno, por lo tanto me desahogo en este blog mientras bebo cerveza artesanal y pienso en un mundo bonito donde Java no existe.

Facebook Twitter LinkedIn  

Entradas relacionadas:

Un comentario en: “¿ Pro/dev ? hacker garage Guadalajara

  1. Como dices considero que es parte de la ética del programador.
    Si necesitas a alguien que te pique las costillas para hacer un buen trabajo, entonces el problema no es la empresa.
    Por otra parte, se nota la diferencia cuando una empresa y la comunidad apoya las buenas prácticas; es una influencia a quien no lo ejecuta.
    Pero bueno, es complicado cuando se tienen muchos clientes y poco tiempo; sigue siendo el problemas de las tres B, bueno, bonito y barato. Solo se pueden tener dos (y agregar “rápido”).

    Creo que el mayor problema es que también la gente solo lo ve como algo “ético”, cuando hay incluso un término para las consecuencias del “al ahí se va”: Technical Debt
    https://en.wikipedia.org/wiki/Technical_debt

Leave a Reply

Your email address will not be published. Required fields are marked *