Hay que ver que es malo … porque muchas veces muchos programadores orgullosos que creen programar “bueno” pretenden condicionar el negocio… y es eso bueno?
Tal vez algunos programadores “malos” entregan a tiempo (una truchada) … sin utilizar tiempos adicionales a los que el cliente paga, y permitiendo poner en marcha el nuevo sistema y que el cliente lo use.
Muchas “buenas practicas” son definidas en cierto entorno y a veces exigidas y usadas en otro entorno donde no tiene razon de ser.
Doy 2 ejemplos:
- Sobre una aplicacion pese a que nadie lo pedia, declare que era riesgoso tenerla sin casos de tests… me costó muchisimo convencer a lideres de proyecto, cliente y gerentes de que habia que apartar tiempo para agregar casos de test, hasta que lo consegui. Apenas termine de implementarlo… el cliente nos sacó ese proyecto, se lo dio a otro proveedor y a nuestra empresa le dio un sistema mas grande…. por lo cual … los tests que hice (lo correcto) nadie lo utilizó nunca.
- Ejemplo 2: Mi generente me especificaba… si le damos lo que el cliente pide, y no tiene la maxima calidad, tal vez podemos luego venderle un mantenimiento mensual para subsanarlo.
Si le queremos enseñar al cliente como deberian estar las cosas bien… pudiera ser que termine contratando el proyecto de otro proveedor que le promete eso.
Muchas veces cuando se mencionan programadores “buenos” se tienen en cuenta parametros academicamente utiles. O que van a ser geniales, cuando el sistema escale, y seguramente cuando el sistema escale para que eso sea un problema la empresa deberia tener un presupuesto para replantear el sistema. Y lo menciono como buena practica, porque nadie sabe con certeza que parte de la aplicacion o que caracteristica sera la que mas use la comunidad.
Por eso hoy existe un criterio bastante acertado que es “SELL FIRTS, FIX LATER”,, porque la realidad es que cualquier proyecto se acaba si no se producen entregables constantemente.
De hecho mucho del negocio de ayudar a Startups, tiene que ver con entregar pruebas de concepto que permitan arrancar el negocio, y si eso explota (para bien) y crece, ese es el momento de pensar como hacerlo “bien”
La calidad es infinita, y el crecimiento nadie sabe para donde va… por eso si funciona… noto que muchas discusiones de buena o mala programacion tienen que ver con una discusion salarial y comparativa que no se menciona.
Si hay una practica beneficiosa que se debe cumplir si o si deberia estar automatizado su control y el propio entorno no deberia permitir que el desarrollador comitee. Todo lo demas, es filosofia de la computacion.
La unica buena practica de computacion que es indiscutible es la buena seleccion de nombres porque indica cuan bien se entendio el problema. Todo lo demas es solucionable y mejorable. Y no siempre los que lo quieren imponer tienen los elementos cuantificables para justificar su decision. A veces proponen cosas por ejemplo para mejorar la performance en entornos donde la diferencia no tiene una incidencia cuantitativa y asi por el estilo.
Quier añadir un comentario para poner a prueba la exigencia de la calidad. Cada vez que alguien se quejaba de un programador de mi equipo le peguntaba “Que regla ‘escrita’ no siguio? Porque reglas habladas y generales todos dan, aun contradictorias. Por otra parte todos saben lo que habria que haberse hecho despues que el problema ocurre. Ahora… quie fija “ANTES” el parametro para evitar que ese problema ocurra? Y una cosa mas… es una buena practica que la cantidad de buenas practicas tenga un numero que pueda ser facilmente implementable. Ya he visto instalaciones de plugins con un sinnumero de restricciones que ademas de retrasar el proyecto o poner de mal humor a los programadores no traian un beneficio medible, Y los programadores con mas experiencia lo que aprendian era como saltear esos controles.