Archivo

Archivo para Jueves, 25 de noviembre de 2004

Dogmatismos de la programación: ¿Qué hacer si usted se topa con uno de estos casos?

Jueves, 25 de noviembre de 2004

Todo el mundo se encuentra en algún momento de su vida con opiniones contrarias al sentido común; Muchas veces una persona es elevada de posición dentro de la compañia sin estar lo suficientemente preparada para “guiar con ejemplos”. Si la compañia es grande, un número más grande de personas revisa el proceso y tiende a depurar este tipo de problemas (y personas) con el tiermpo, pero si es pequeña es más dificil lidiar con esto porque la responsabilidad recae sobre unos pocos, y estos son los que hacen los estándares.

No me malentienda; Los estándares son buenos cuando ayudan a formalizar un proceso y elevan la calidad y eficiencia; Pero si no se deja un espacio libre para questionar la autoridad (entiendase, corregir errores), entonces el sistema degenera ya que los empleados no sienten que son parte del proceso creativo de la compañia, además de que están violando principios por seguir un dogma.

Veamos primero la definición de lo que es un Dogma:


La palabra dogma (del griego dokein) se usa a veces, en los escritos de los autores clásicos antiguos, para significar una opinión o lo que parece verdadero a una persona; otras veces, para señalar una doctrina o posición filosófica, especialmente si se trata de las peculiares doctrinas de una escuela particular de filósofos (Cfr. Cic. Ac. II,9). A veces también se refiere a un decreto u ordenanza pública, un dogma poieisthai.

Aqui le tengo una pequeña lista de dogmas, la cual tomé prestada de un personaje de la vida real:

  1. Every package should have the company initials prefixed to the class name. On SQL every table an attribute should have their name prefixed with the company inittials (Todo paquete debe tener las inciales de la compañia como prefijo agregadas a el nombre de la clase. En SQL toda tabla y attributo debe tener como prefijo las iniciales de la compañia): Las bases de datos tienen limitaciones en la cantidad de caracteres que se pueden usar como un identificador (por ejemplo Sybase tiene una limitación de 30 caractéres). ¿Porqué gastar esos caracteres en un identificador usando un prefijo inútil cuando se pudieran usar para tener un identificador más claro? Esta medida en todo caso es justificable sólo en los nombres de las tablas y quizas las bases de datos, pero es exagerado en las columnas.
  2. The code is the documentation (El código es la documentación): Esto es ridiculo. Si bien muchas veces el código es la única documentación disponible, ciertamente hay veces en las cuales el proposito del API no es lo suficientemente claro; Además tener una documentación adecuada puede ayudarlo a recordar elementos complicados de su programa meses después.
  3. Use make for everything (Utilice make para todo): Alguien dijo que “si usted tiene sólo un martillo, todo se verá como un clavo”. Por ejemplo, Ant es mejor que Make para Java debido a su mejor manejo de dependencias y su buena integracion con entornos integrados de programación (IDE).
  4. Servers have to be rebooted when not used (Los servidores deben ser reiniciados cuando no sean usados): Quizas esto aplicaría para un servidor de desarrollo, pero nunca para un servidor de producción al menos que se tenga redundancia y manejo de sesiones (una solución de cluster). Si bien el software de un sistema operativo siempre va a tener defectos, eso no implica que no pueda estar encendido la mayor cantidad de tiempo posible, prestando servicio ininterrumpido (sólo vea como se portan Linux, FreeBSD o Solaris). En la compañia actual tenemos servidores que han estado arriba por más de un año, sin ningún problema.
  5. The code doesn’t follow the company coding standards and hence is inferior. But there are no published standards (El código no sigue los estandares de la compañia y por lo tanto es inferior. Pero no existen standares publicados): De nuevo, no crea en estandares que no han sido aprobados por quienes tienen poder de decisión en la compañia. Si se consigue con un dogma, trate de averiguar la razón de este y busque ya sea adaptarse a ese estandar o proponga un cambio, pero no sea un complice de una medida mediocre.
  6. The developer has some much experience in the industry than feedback from the domain experts is not required, actually affects the product vision (El desarrollador tiene tanta experiencia de la industria que los expertos de dominio no son requeridos, actualmente afecta la visión del producto): No sólo es arrogancia sino estupidez. Tenga cuidado con este tipo de desarrolladores, ya que por sen tan testarudos (y pesados) dentro de la empresa, pueden hacer fracasar proyectos. Yo en este caso tengo una anecdota: Este desarrollador diseñó la interfa gráfica de un producto financiero, busco los clientes y además hizo el código de el motor analítico, todo sin preguntar; Claramente aqui hay problema de control y por no saber delegar nunca entregó los artefactos requeridos a tiempo. Usted como desarrollador presta un servicio, y debe escuchar a una persona llamada el “experto de dominio” quien sabe como resolver el problema. Si bien usted debería tener conocimiento del área en la que trabaja, es el experto de dominio quien define como resolver una parte crucial del problema. Otra cosa, un desarrollador no define los requerimientos de un producto, es el cliente quien lo hace.

  7. On SQL, Foreign keys are evil and if required then replace them with either stored procedures or triggers (En SQL, las claves externas son malas y si son requeridas reemplacelas con ya sea procedimientos de el lado del servidor o activadores): Las claves externas existen para garantizar la integridad de los datos y para ilustrar relaciones de dependencia de datos. Más de una vez, yo he visto como la data se ha salvado de un error de programación debido a que la base de datos lo proteje de este tipo de errores; Además, es casi garantizado que la compañia que hizo el manejador ya optimizó este tipo de código porque su proposito es bien especifico, a diferencia d eun procedimiento del lado del servidor (stored procedure), el cual pudiera tener hasta errores de lógica.

Como puede ver, cada uno de ellos existe para resolver un problema, pero a la larga pueden dañar la productividad de el equipo, la moral de este, o el desempeño de las aplicaciones. Incluso los desarrolladores más creativos (pero con menos poder de decisión dentro de la compañia) se iran de esta, porque un dogma sólo asusta el talento.

¿Y como lidiar con una situación de estas? La pregunta no tiene respuesta fácil y depende de la situación. Pero por lo general, ustéd (si es quien no está de acuerdo con la medida) deberá convencer a quienes tienen poder de veto con argumentos sólidos y deberá también prepararse para una respuesta negativa; En todo momento usted deberá ofrecer una alternativa al método que está fallando, de lo contrario sólo parecerá que usted no pudo salirse con la suya y que sus argumentos carecen de merito.

Y sobre todo, sea considerado en como plantea el problema. A nadie le gusta escuchar que está equivocado, sobre todo cuando la solución que está implantada es mejor que no tener ninguna solución.

Sin categoría