March 29th, 2010 Programación, Top Gustavo Villavizar 13 Comentarios

Ayer leía con una sonrisa en mi rostro un tema escrito por Keving William Pang llamado “Top 10 Things That Annoy a Programmer” y aunque estoy 100% de acuerdo con el, creo que solo 10 cosas no son suficientes, así que aquí van las 10 cosas que según él molestan a un programador (traducidas por mi) y luego MIS 10 cosas que molestan a un programador.

10. Comentarios que explican el “cómo” pero no el “porqué”

Esto es típico, estamos programando en el código de otro y nos encontramos con esto:

r = n / 2; // Set r to n divided by 2
// Loop while r - (n/r) is greater than t
while ( abs( r - (n/r) ) > t ) {
r = 0.5 * ( r + (n/r) ); // Set r to half of r + (n/r)
}

Y el principal problema con esto es que yo entiendo lo que hace el código, si estoy trabajando con tu código es porque sé cómo funciona un while(), lo que no entiendo (y necesito entender) es con qué objetivo usaste un while en esta parte del programa. A veces cuando comentamos no nos detenemos a pensar la relevancia del comentario, sino que como está comentado ya estamos cumpliendo, tomen por ejemplo el código anterior, cambiemos el comentario y veamos si entendemos algo.

// square root of n with Newton-Raphson approximation
r = n / 2;
 
while ( abs( r - (n/r) ) > t ) {
    r = 0.5 * ( r + (n/r) );
}

Ok, para muchos seguirá siendo incomplensible, pero para un programador al menos nos pone en el camino correcto de qué hace este bloque de código. Es una de las peores cosas de trabajar con el código de otro.

9. Interrupciones

Muy pocos programadores pueden ir de 0 a código en un instante. Por lo general un programador toma tiempo para introducirse en el código, pero una vez que lo hacemos podemos escribir miles y miles de líneas de código semánticas sin detenernos. Desafortunadamente es muy dificil entrar en la zona de programación cuando estamos siendo constantemente distraídos por clientes, compañeros de trabajo o jefes todo el tiempo, incluso otros programadores.

Algo que aprendí en mi trabajo en comuniQue es que lo mejor para programar definitivamente es desconectarse del resto del mundo.

Mientras programamos debemos manejar demasiada información en nuestra mente, es decir, antes de comenzar debemos tener una visión del objetivo final y luego separar ese objetivo en partes y trabajar en pequeñas porciones, pero cada porción debe ir de la mano con las demás para que mantengan concordancia. Esto es algo dificil de entender para la mayoría de los no-programadores. Las distracciones nos sacan de nuestra área y generalmente toma demasiado tiempo volver a ella.

8. Scope creep

Desde Wikipedia:

Scope creep (also called focus creep, requirement creep, feature creep, and sometimes kitchen sink syndrome) in project management refers to uncontrolled changes in a project’s scope. This phenomenon can occur when the scope of a project is not properly defined, documented, or controlled. It is generally considered a negative occurrence that is to be avoided.

No tengo mucho que decir de esto, solo pensarlo me pone los nervios de punta…pero miremos un ejemplo práctico que Kevin da:

  • Versión 1: Mostrar un mapa de la ubicación
  • Versión 2: Mostrar un mapa 3D de la ubicación
  • Versión 3: Mostrar un mapa 3D de la ubicación en la que el usuario pueda navegar

Así de sencillo un requerimiento que en el primer planteamiento fue relativamente sencillo y de unas pocas horas de integración se convirtió en un total dolor de cabeza para cualquier programador. Este tipo de “adiciones” a un requerimiento generalmente ocurren durante el desarrollo y esto requiere reescribir, reestructurar y a veces votar porciones de código que previamente teníamos.

7. Gerencia que no entiende de programación

Resumiendo: Cuando la gerencia no conoce ni los conceptos básicos de nuestro trabajo, terminamos con Scope Creep, deadlines irrealistas y en general frustración de ambos lados de la mesa. Esta es una queja común entre programadores y la fuente de mucho enojo.

6. Documentar nuestras aplicaciones

Ok, desde siempre se nos ha dicho que debemos documentar todas nuestras aplicaciones, pero es un dolor en el @$$, miren todos los programas open source que hay en internet, qué es lo que normalmente buscan cuando alguien se ofrece a ayudar…”escribir la documentación”.

La causa de esto es simple, para cualquiera que esté en este trabajo es porque disfruta este trabajo. Siendo realistas, nadie escribiría 3786 lineas de código de no disfrutarlo. Documentar no es parte de nuestro trabajo, estamos a gusto escribiendo código que solo unos pocos entienden, pero la verdad carecemos de la capacidad de escribir una documentación que cualquiera pueda entender…a la hora de escribir documentación no podría hacerlo alguien más?

5. Aplicaciones sin documentación

Si, es una contradicción completa al punto anterior, estamos de acuerdo en que odiamos documentar, pero eso no significa que no la necesitemos.

4. Hardware

Es un error común el creer que solo porque somos programadores podemos reparar una computadora que no sube, una impresora que no imprime o una máquina que no tiene acceso al servidor. En muchos casos es cierto, pero en muchos otros no. Los no-programadores o en este caso no-informáticos en general tienden a creer que cualquiera que trabaje con algo relacionado a las computadoras debe saber repararlas, y esto no es cierto.

Un programador solo desea que las cosas funcionen  como deben de funcionar para que podamos seguir con nuestro trabajo. Esto pasa en compañías que tienen programadores pero no tienen nadie encargado de TI, así que en muchas ocasiones el programador debe dejar de programar y pararse a ayudar a un vendedor que no puede abrir una presentación de powerpoint en su pc, siendo que la presentación es para 2007 y la pc tiene 2003…y eso, eso es frustrante!

3. Vaguedad

Antes que todo si, la palabra existe.

Ahora al punto, “el website no funciona”, “no puedo loguearme”. Es un caos trabajar con requerimientos vagos. Es sorprendente ver como los no-programadores se ponen cuando se les pide que reproduzcan el error para el programador. Parecen no entender que “está dañado, repáralo” no es suficiente información para resolverlo.

Por eso muchas veces se dice “intenté reproducir el error y no logré hacerlo, por tanto, todo está funcionando correctamente“, esto no significa que el programador sea vago, significa que necesitamos saber el navegador, el sistema operativo, la velocidad de conexión, los datos que se estaban introduciendo, desde donde y hacia donde se dirigía cuando surgió el problema, si los CAPS Lock estaban activados o no, si el teclado es en inglés o en español…todo esto es necesario para poder encontrar y reparar un error.

2. Otros programadores

No comentarios en este punto…el título es muy obvio.

1. El código propio, 6 meses después

Para un no-programador puede ser dificil entender este punto, pero la base de un buen programador es la evolución constante. Un programador que no evolucione en 6 meses ya no puede llamarse a si mismo programador.

Lo cierto es que cada vez que tenemos que volver a trabajar en una aplicación que hicimos hace 6 meses o un año, muchas veces preferimos escribir el código desde 0. Esto no es malo, es solo que a un programador le cuesta mucho seguir las malas prácticas, la tecnología y la programación como tal evolucionan, la forma de hacer algo hoy es mucho más sencilla que la forma de hacer eso mismo hace 6 meses, por tanto es repulsivo tener que trabajar con un código no óptimo.

Les pongo un simple ejemplo, en cierto proyecto necesitaba mostrar una fecha en español desde la base de datos. Este fue el primer código que usé:

$fecha = explode(" ",$item['fecha']);
$date = explode("-",$fecha[0]);
$time = explode(":",$fecha[1]);
$dia = date("l", mktime($time[0], $time[1], $time[2], $date[1], $date[2], $date[0]));
$search = array("Sunday","Monday","Tuesday","Wednesday","Thursday","Friday","Saturday");
$replace = array("Domingo","Lunes","Martes","Miércoles","Jueves","Viernes","Sábado");
$dia = str_replace($search,$replace,$dia);
$mes = date("M", mktime($time[0], $time[1], $time[2], $date[1], $date[2], $date[0]));
$search2 = array("Jan","Apr","Aug");
$replace2 = array("Ene","Abr","Ago");
$mes = str_replace($search2,$replace2,$mes);
$meridiano = date("a", mktime($time[0], $time[1], $time[2], $date[1], $date[2], $date[0]));

Rústico si, pero funcionó bastante bien. Luego perfeccioné ese código, en un nuevo proyecto descubrí que puedo lograr el mismo resultado con el siguiente código:

setlocale('es_ES');
strftime('%A %d de %b del %Y a las %X',strtotime($item['fecha']));

Cool eh? Acabo de convertir 12 líneas de código en 2…imagínen mi impresión cuando tuve que volver a trabajar con el primer proyecto y me encontré con ese código…qué creen que hice, lo dejé tal cual y resolví el asunto o lo cambié por el nuevo código? Por supuesto que lo cambié, si no lo hubiera hecho no habría podido dormir esa noche (si, así de grave es mi caso), en este caso no vale eso de que si no está roto no lo arregles, porque desde el punto de vista de un programador SI ESTA ROTO.

Estas son las 10 cosas que molestan a un programador según Kevin William Pang, ahora les expreso otras 6 cosas que molestan a un programador según Gustavo Villavizar.

6. La superposición del cliente

La superposición del cliente indica cuando un cliente solicita un nuevo feature a una aplicación, el contacto del cliente le dice “Ok”. Esa persona no hace preguntas, no sabe hacerlas, por tanto le queda al programador la tarea de realizar ese requerimiento sin importar si conviene o no, si es factible, si es posible, pero hay que hacerlo porque ya se le dijo al cliente que si.

5. Trabajar con el código de otro

Este caso indica una relación entre varios puntos que he mencionado antes…es dificil trabajar con el código de otro.

4. Demasiados nodos en la cadena

Esto es demasiado común. Cuando hay muchos intermediarios entre el cliente y el programador se hace mucho más dificil desarrollar los requerimientos del cliente. El cliente hace un requerimiento, tarda mucho tiempo en llegar al programador y si el programador lo rechaza tarda mucho en llegar de nuevo al cliente, en esta etapa el cliente entiende que al haber pasado tanto tiempo su requerimiento fue aceptado y que se está trabajando en eso, es problemático cuando se le cambia la idea al cliente con la respuesta del programador.

3. Gente que cree que sabe programar

Un ingeniero de sistemas graduado en 1993, un programador de Cobold, un programador de aplicaciones Win32 que creen que saben cómo programar para web…¡esto es fatal! Por favor entiéndelo, Windows y la Web no funcionan igual.No eres programador web así que deja de pensar que entiendes mi trabajo o pero aún, que sabes más que yo del mismo.

Esta es una de las principales razones por las cuales un programador independiente rechaza un proyecto luego de haberlo iniciado, no es por falta de responsabilidad, es que se vuelve imposible trabajar así.

2. Clientes que lidian con términos complejos de los cuales no entienden

A veces, cuando las estrellas se alínean, algún no-programador lee un post sobre programación o escucha una conferencia y aprende términos nuevos, y los quieren usar.

Cuando te piden un proyecto minimalista como el website de Apple, generalmente quieren una página con fondo blanco y muchas imágenes. Cuando te piden que el proyecto tenga la tendencia KISS pero que tenga 13 mil features, cuando te piden que la página sea fácil de usar pero que tenga comunicación de marca, etc.

1. Cuando creen que el programador también es diseñador y hasta copywriter

¿Alguien se siente identificado con esto? El cliente hace un requerimiento y el programador debe realizarlo, integrarlo con el diseño y escribir el texto correcto en el website…cuesta trabajo decirle a un cliente que somos programadores, no diseñadores ni copywriters, y peor aún es cuando se lo has dicho en los dos requerimientos anteriores y en este tienes que repetirselo.

Leyendo todo el post nuevamente parece una especie de rabieta, pero estoy seguro de que mis colegas programadores y algunos no-programadores se sentirán identificados con algunos de los puntos que expreso en esta entrada.

Si olvidé alguno, son bienvenidos a expresarlos en los comentarios.

  • http://retrorock.info Wilbur Suero

    A mi me molesta cuando tengo que trabajar con un deadline hecho por otros y tomado sin consideraciones, especialmente cuando no se cumple.

    Y cuando la primera linea de un requerimiento comienza con “Esto solamente tiene que …”

  • http://luis3ignacio.blogspot.com Ignacio Cortorreal

    “Eso yo lo hago de una vez! Quieres que lo haga yo?” A veces me da deseos de decirle “Sí! Hazlo!”

    “En .NET y en NetBeans yo lo hago de una vez!”, pero quieren que se vea con el mismo look de una página de Apple.

    Vamos a traducirlo a 5 idiomas… Vamos a agregarle unos nuevos niveles de usuario… Ok, ahora vamos a cambiar la base de datos a Oracle o SQL Server…

    Y lo quiero para ya! … !”#$%&/(

  • Cristian Matos

    Cliente: Men cotizame este projecto

    Programador: Ok, todo eso te sale por 50,000 en 2 meses

    Cliente: WTF! pero yo conosco un fulano que me lo hace en 10,000 en 3 dias.

    Programador: :S

    ———————————————–
    Hey Ignacio y Wilburg dos programadores fuerte, lo se porque hemos trabajado juntos xD.

  • http://kamekun.blogspot.com KaMekUn

    Un gerente viene y te dice, eso se hace facil debemos entregar esto en unos dias sencillo verdad?, cuando no ha tomado ni el tiempo de definir que exactamente que se requiere, porque por lo general no es un cambio o feature es un listin de cosas por hacer y al final te dice ahora se ve muy cargado….

    Saludos, Muy Buen post men.!

  • http:///www.puntiel.com Juan Puntiel

    No me gusta documentar mucho, eso provoca que pierdes la logica que tienes en la RAM de tu cabeza.

    Otra vaina que me quilla de la programacion web:
    No-programadores, Internet Explorer no sirve, dejen de usar esa vaina, Dios santo, que dolor de cabeza…..

  • http://purocodigo.com Melvyn Pérez

    El 8 y el 3 de Kevin William

    Las 6, 5, 4, 3, y 1 de Villavizar me tienen completamente loco. Por eso suelo mandar al #$%#@$% a mis compañeros constantemente.

    Increible, me vi en el espejo.

  • http://purocodigo.com Melvyn Pérez

    Ah… se me olvidaba: La documentación. Aclaremos algo: la 6 y la 5 no se contradicen. Una cosa es documentar el código, otra es documentar como funciona la aplicación (Manual de usuario/ayuda).

    Vamos a poner las cosas claras:
    Si el código esta bien escrito se explica a sí mismo. Sin embargo los programadores de verdad no documentan; si fue difícil de escribir, debe ser difícil de entender.

  • Carlos

    Haciendo referencia al tema 10 y al tema 6 de lo que gustavo comenta, estoy muy de acuerdo con el. Creo que hay que documentar y que es una practica que debe hacerse siempre porque hasta los expertos y mejores programadores del mundo lo hacen, y mejor todavía por algo mas vital y de suma importancia… Las personas que le darán mantenimiento a la aplicación puesto que es muy probable que no seas tu siempre el que le de soporte y mantenimiento a dicha aplicación. El no documentar es una mala practica e implica un dolor de cabeza para el que tiene que entender de raíz que hizo el creador del programa y peor aun, atrasa el desarrollo de la empresa en cierto ámbito en cuanto a cuestión de tiempo.

  • Carlos

    Por otro lado, se que el no documentar desencadena un sentimiento oculto de mucho “cariño” por el programador que le toca darle mantenimiento a la aplicación de otro que no documenta…. Es algo como : What the F..k is this?, Damn! who the F..k did this? y asi sucesivamente. Es una forma de ganar cariño así que por ese lado el no documentar es bueno…lol.

  • afarias

    que un compañero por X motivos te halla modificado el código y no te avise!!! para matarlo

  • tuporaqui

    No estoy de acuerdo con los comentarios que dicen que documentar el código no es trabajo del programador… será “aburrido”, pero ES RESPONSABILIDAD DEL PROGRAMADOR, es parte de su trabajo, no sólo una buena práctica. Desgraciadamente, no todo en el trabajo es hacer lo que más nos gusta.

  • Mike

    Cobold o Cobol, pedazo de bruto??? Seguramente perteneces a esa generación de programadores cabeza sin estudios, sin formación.
    A mi lo que más me molesta son los programadores con deficiente formación matemática. Si hay algo que la matemática de la facultad te enseña es a optimizar y buscar soluciones simples. Odio los programadores que se complican solos la vida, metiéndose en un nudo del que no pueden salir fácilmente después.

  • Jibran

    A mi me molesta que aveces me esfuerzo tanto que me quedo sin tareas por realizar….. como ahora aburridisimo….

Archivos