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.

Hace poco tuve una reunión con un cliente donde me definieron lo que querían lograr con su página web. Lo que pude ver fue muy agradable, me di cuenta de que realmente quieren sacarle provecho a su página web (en contraste con lo que tenían anteriormente en una página meramente informativa).

Generalmente los website “corporativos” se caracterizan por transmitir la imágen de la empresa, pero muy a menudo pierden algo fundamental, y es la usabilidad. Muchas veces he visto en websites corporativos donde la mayor interactividad que el usuario tiene con la página es llenar un formulario de contacto.

He recopilado una serie de cosas que, a mi entender, un website corporativo debe tener para que pueda servir de algo para el cliente de la empresa.

1. Sección de Noticias
Cuando visito un website corporativo, quiero ver si la empresa todavía está viva, es decir, quiero saber qué ha estado haciendo la empresa en el ámbito corporativo, si ha crecido, si ha participado en eventos, si ha realizado mejoras en sus actividades, etc.

Pero no basta con tener una sección de noticias y listo. Esta sección debe serme útil, debe ofrecerme opciones que vayan más allá de solo leer las noticias.

El sistema de noticias de BNET te permite descargar la noticia en formato PDF, enviarla
por email, compartir la noticia, imprimirla, recomendar la noticia o votar por ella.

Esta es una de las razones por las que muchas compañías escojen un blog frente a un sistema de noticias para manejar las de su empresa.

2. Listado de sus clientes
Esta es un arma de doble filo, pero que no debe quedarse fuera de un website corporativo. La empresa debe demostrar que está orgullosa de sus clientes y que tiene clientes en primer lugar. Al enlistar sus clientes, una empresa demuestra que son confiables, que tienen calidad y que tienen profesionalidad, mientras más grande el cliente mejor.

Lo malo de esta parte es que a menudo las empresas deciden listar en sus páginas únicamente a aquellos clientes grandes que puedan darle representación. Pero sus clientes medianos y pequeños se sienten como si la compañía los considerara insuficientes para ser listados en el website de la empresa cuyo servicio contrataron.

Otro problema de mencionar solo los clientes grandes, es que cuando un cliente mediano o pequeño ve la lista de clientes, a veces duda siquiera de contactar con la empresa pues siente que no posee el perfil adecuado para contratar esta compañía. Ejemplo; un cliente que requiera de un pack de íconos para su nueva aplicación no contactaría al diseñador que solo muestra en su portafolios trabajos para Apple, Microsoft, Dell, etc. Simplemente busca algo un poco más cercano a su budget sin siquiera preguntar por precios o paquetes.

Yellow Icon muestra por orden alfabético a todos sus clientes,
sin importar que tan grandes o pequeños sean.

Es importante mencionar todos los clientes ya sean grandes y pequeños, o al menos una buena cantidad de cada uno.

3. Equipo
La mayoría de las empresas (por no decir todas) dicen en sus textos que su equipo es una parte vital de la empresa y lo orgulloso que están de ellos, sin embargo muy pocos tienen una página dedicada a su equipo.

Las personas contratan personas, no contratan computadoras, por esto, es bueno que las personas sepan a quiénes están contratando.

Puede ser solamente una foto del equipo, una foto acompañada del nombre, una pequeña “bio” de cada empleado o ir mucho más allá y poner un link a la página personal del empleado, la forma de incluirlo dependerá de la empresa, pero siempre es bueno saber a quién se debe admirar o aborrecer por las acciones de la compañía.

Dellustrations incluye una página entera dedicada a su equipo e incluso van más allá
y ponen links al perfil de LinkedIn de cada uno cuando aplica.

4. Historia
Todo website corporativo debería incluir una historia de la trayectoria de la empresa. Nos gustan las personas emprendedoras, no es malo mostrar que la empresa ha fallado en algún momento pero que ha aprendido de sus errores y ha seguido adelante. No importa que tan corta o larga sea la historia (mientras esté bien segmentada), quiero saber desde cuándo ha estado ahí la empresa para poder determinar si seguirá ahí siempre que la necesite.

Duarte tiene una hoja de historia bastante completa con fotos de
todas las eras de la compañía.

5. Definiciones
Algo que me parece curioso es que la mayoría de las empresas se dirígen directamente a un público que entiende lo que se está vendiendo.

Considero que al momento de enlistar los servicios o productos que ofrece una página, es vital incluir una pequeña definición de dicho producto o servicio para aclarar al cliente sobre cualquier duda que pueda surgir. A veces navegamos por una página pero no sabemos todo lo que hace la compañía, a lo mejor lo que la compañía me vende es justo lo que yo necesito, pero no tengo el conocimiento para entender que lo que me venden es lo que estoy necesitando.

comuniQue ofrece definiciones claras y precisas sobre
cada uno de los servicios que ofrece en su web.

Al final cada website corporativo debe ser único, pero aún así hay prácticas que cada uno debe emplear para que su negocio pueda ser confiable y rentable. Quiero aclarar que los conceptos emitidos en este post son de mi criterio personal, un website puede ser usable sin necesidad de estos elementos, pero los considero factores clave para que la empresa transmita una mejor imágen de si mismo.

Con el trabajo de un proyecto (que por cierto aún no puedo mostrar), el cliente pidió un intro en flash para su página. Le recomendé que no lo hiciera, que ya no se usaban, que eran molestos, etc…pero el cliente lo quería…

A continuación doy 5 razones por las que no usar intros en flash.

5. Mucho tiempo de espera

Un problema de los intros en flash es que nos obligan a ver una animación que no nos interesa en un tiempo que para nosotros es valioso. Recordemos que lo importante es captar la atención del usuario en un lapso de 30 segundos…¿cómo podemos captar la atención de los usuarios si no les mostramos algo que desean ver durante 30 o 45 segundos que dura una animación?

Claro, podemos poner un botón para “saltar intro” pero entonces ¿para qué es el flash?

Y quiero hacer énfasis en este punto. Para que la animación pueda verse satisfactoriamente, es necesario una muy buena conexión a internet o en su defecto que el flash cargue toooodo lo que va a utilizar antes de empezar a correr. Esto suma tiempo a la duración de la animación, así que imagínense tener que esperar 1 ó 2 minutos a que cargue una animación de 30 segundos que tampoco me es útil.

4. No distinguen las necesidades del usuario

Imagínese entrar a amazon.com a comprar un nuevo libro y tener que soportar un flash con los productos de oferta del momento (laptops de $900 dólares, televisores de $700 dólares, etc.). Esto no es lo que yo busco, yo tengo un interés y quiero llegar a la información que busco cuanto antes. Si quieren mostrarme las ofertas del momento, pongan los anuncios en la página que yo entré a ver (en este caso los libros).

3. No representan los gustos del usuario

Si su website es sobre animales, la única forma de llamar la atención de sus usuarios es incluir todos los animales que tiene en la animación, pero esto aumenta el tiempo del flash. Puede incluir algún animal en específico, pero de nuevo, esto no es lo que estoy buscando. En este sentido, es necesario poner algo que les llegue a todo el mundo o algo que definitivamente solo le llegará a unos pocos.

2. Siguen solo un estilo de animación

Hay diversas formas de animar un intro. Pueden hacerlo al estilo Jumbo (rapido y radical), al estilo Provaltur (lento y suave), etc. El problema es que cada usuario tiene gustos muy específicos en cuanto a esto. Un website no debe discriminar a sus usuarios.

1. Mucha repetición

Dado el hipotético caso de que el flash no cumpla con los 4 requisitos que mencioné anteriormente, he aquí uno que no se escapa a ningún intro en flash del internet. La repecitión. Solo es interesante la primera vez que lo vemos, luego se convierte en un click extra para ver lo que queremos ver. El usuario se cansa de tener que ver el mismo flash cada vez que entra, claro, podemos poner un botón para “Saltar Intro” pero repito, entonces ¿para qué es el flash?

¿Qué hay de ustedes? ¿Tienen alguna otra razón por las que no se deben usar intros en flash? De su parte ¿qué es lo que realmente opinan de esta tendencia que, gracias a Dios, se está quedando en el pasado?