Saltar al contenido

Artículos, tutoriales, trucos, curiosidades, reflexiones y links sobre programación web ASP.NET Core, MVC, Blazor, SignalR, Entity Framework, C#, Azure, Javascript... y lo que venga ;)

17 años online

el blog de José M. Aguilar

Inicio El autor Contactar

Artículos, tutoriales, trucos, curiosidades, reflexiones y links sobre programación web
ASP.NET Core, MVC, Blazor, SignalR, Entity Framework, C#, Azure, Javascript...

¡Microsoft MVP!
lunes, 13 de octubre de 2008
Aaarg!Me ha parecido muy interesante y divertido el post de Kevin Pang, "Top 10 Things That Annoy Programmers", en el que obtiene los factores más irritantes para los desarrolladores combinando su propia experiencia con los resultados de una pregunta realizada en StackOverflow, la famosa comunidad de desarrolladores promovida por los populares Joel Spolsky y Jeff Atwood.

Además de estar casi totalmente de acuerdo con los puntos expuestos en su post, que enumero y comento a continuación, añadiré algunos más de propia cosecha de agentes irritantes.
  • 10. Comentarios que explican el "cómo" y no el "qué". Tan importante es incluir comentarios en el código como hacerlo bien. Es terrible encontrar comentarios que son una simple traducción literal al español del código fuente, pues no aportan información extra, en lugar de una explicación de lo que se pretende hacer. Muy bueno el ejemplo de Kevin en el post original... ¿eres capaz de decir qué hace este código, por muy comentado que esté?
    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)
    }
     
  • 9. Las interrupciones. Sin duda, el trabajo de desarrollador requiere concentración y continuidad, y las interrupciones son las grandes enemigas de estos dos aspectos. Una jornada de trabajo llena de llamadas, mensajes o consultas de clientes, proveedores, jefes o compañeros puede resultar realmente frustrante, a la vez que la distracción que introduce suele ser una fuente importante de errores en las aplicaciones.


  • 8. Ampliación del ámbito. Una auténtica pesadilla, sobre todo cuando se produce durante el desarrollo, consistente en el aumento desproporcionado del alcance de determinadas funcionalidades o características del software a crear. Es especialmente desmotivador si, además, no viene acompañado por el aumento del tiempo o recursos necesarios para su realización.

    Kevin incluye en su artículo un ejemplo, algo exagerado pero ilustrativo, de sucesivas ampliaciones de ámbito que convierten un requisito factible en un infierno para el desarrollador; seguro que os recuerda algún caso que habéis sufrido en vuestras propias carnes:

    • Versión 1: Mostrar un mapa de localización
      -- Bah, fácil, sólo tengo que crear una imagen; incluso puedo basarme en algún mapa existente que encuentre por ahí

    • Versión 2: Mostrar un mapa 3D de localización
      -- Uff, esto ya no es lo que hablamos; tendré que currarme bastante más el diseño, y ya no será tan fácil partir de alguno existente...

    • Versión 3: Mostrar un mapa 3D de localización, por el que el usuario pueda desplazarse volando
      -- ¡!

  • 7. Gestores que no entienden de programación. Otro motivo común de irritación entre los desarrolladores es la incapacidad de gestores para comprender las particularidades de la industria del software en la que trabajan. Este desconocimiento genera problemas de todo tipo en una empresa y suponen un estrés terrible para el desarrollador.


  • 6. Documentar nuestras aplicaciones. Lamentablemente, en nuestro trabajo no todo es desarrollar utilizando lenguajes y tecnologías que nos divierten mucho. Una vez terminado un producto es necesario crear guías, manuales y, en general, documentación destinada al usuario final que, admitámoslo, nos fastidia bastante escribir.


  • 5. Aplicaciones sin documentación. A pesar de que entendamos y compartamos el punto anterior, también nos fastidia enormemente tener que trabajar con componentes o librerías partiendo de una documentación escasa o nula. Si lo habéis sufrido, entenderéis lo desesperante que resulta ir aprendiendo el significado de las funciones de un API usando el método de prueba y error.


  • 4. Hardware. Especialmente los errores de hardware que el usuario percibe como un fallo de la aplicación son normalmente muy difíciles de detectar: fallos de red, discos, problemas en la memoria... por desgracia, hay un amplio abanico de opciones. Y lo peor es que por ser desarrolladores de software se nos presupone el dominio y control absoluto en asuntos hardware, lo que no siempre es así.


  • 3. Imprecisiones. Aunque Kevin lo orienta al soporte al usuario, el concepto es igualmente molesto en fases de diseño y desarrollo del software. Las descripciones vagas y confusas son una causa segura de problemas, sea en el momento que sea.

    Son irritantes las especificaciones imprecisas, del tipo "esta calculadora permitirá al usuario realizar sumas, restas, multiplicaciones y otras operaciones"... ¿qué operaciones? ¿divisiones? ¿resolver ecuaciones diferenciales?

    Tampoco es fácil encajar un mensaje de un usuario tal que "me falla el ERP, arréglalo pronto"... A ver. El ERP tiene cientos de módulos, ¿fallan todos? ¿podríamos ser más concretos?


  • 2. Otros programadores. Como comenta Kevin, el malestar que provoca a veces la relación entre programadores bien merecería un post independiente, pero ha adelantado aspectos que, en su opinión, hace que a veces el trato con los compañeros sea insoportable:

    • Personalidad gruñona, hostilidad
    • Problemas para comprender que hay que dejar de debatir la arquitectura del sistema y pasar a realizar las tareas
    • Falta de habilidad para mantener una comunicación efectiva
    • Falta de empuje
    • Apatía hacia el código y el proyecto


  • 1. Tu propio código, 6 meses después. Sí, es frustrante estar delante de un código aberrante y darte cuenta de que tú eres el autor de semejante desastre. Y tras ello llega la fase de flagelación: ¿en qué estaba pensando cuando hice esto? ¿cómo fui tan estúpido? uff...

    Este hecho, sin embargo, forma parte de la evolución tecnológica, personal y profesional; todos estos factores están en continuo cambio, lo que hace que nuestra forma de atacar los problemas sea distinta casi cada día.

Siempre acaba pagándola el más tonto...Y hasta aquí la lista de Kevin en su post, ni que decir tiene que comparto sus reflexiones en la mayoría de los puntos. Por mi parte, añadiría los siguientes agentes irritantes que conozco por experiencia propia o de conocidos:
  • Extra 1. Requisitos evolutivos, como una ampliación del ámbito del punto 8 ;-), que son aquellos que van cambiando conforme el desarrollo avanza y que obligan a realizar refactorizaciones, descartar código escrito, e introducir peligrosas modificaciones, afectando a veces por debajo de la línea de flotación del software. Más rabia produce, además, cuando se atribuyen una mala interpretación por parte del desarrollador de una especificación imprecisa.

  • Extra 2. Problemas en el entorno. Nada más frustrante que cortes en el suministro eléctrico, cuelgues, problemas en el hardware, lentitud en los equipos de trabajo o de acceso a información... a veces parece que tenemos que construir software luchando contra los elementos.


  • Extra 3. El "experto" en desarrollo de software. Clientes, gestores y otros individuos que utilizan frecuentemente, y sin conocimiento alguno de causa, expresiones como "Esto es fácil", "Una cosa muy sencilla", "¿Eso vas a tardar en hacer esta tontería?".... A veces no es fácil hacer entender que la percepción externa de la complejidad es absolutamente irreal, y suele ser una causa frecuente de desesperación para los desarrolladores.


  • Extra 4. Usuarios corrosivos, que lejos de colaborar durante el desarrollo o la implantación de un sistema, aprovechan la ocasión para arremeter contra la aplicación, organización, jefes, compañeros, el gobierno, o lo que se ponga por delante. Es de justicia decir que muchas veces este comportamiento es debido a una mala gestión interna del proyecto, pero desde el punto de vista del profesional del sofware que sólo quiere realizar lo mejor posible su trabajo son una auténtica pesadilla.


En fin, que ya a estas alturas es fácil ver que hay bastantes cosas que fastidian a los desarrolladores, y seguro que podríamos añadir muchas más; algunas son evitables, otras son inherentes a la profesión y hay que aprender a convivir con ellas, pero en cualquier caso son un interesante motivo de reflexión.

¿Y a tí, qué es lo que más te fastidia?

Enlace: Top 10 Things That Annoy Programmers
Publicado en: www.variablenotfound.com.

12 Comentarios:

Vamos por todo dijo...

Cuando viene un jefe y dice que necesita esta nueva funcionalidad para ayer. Eso me irrita terriblemente. Y me pregunto por que no me lo pediste hace una semana. O me tomo el Delorean y viajo en el tiempo para resolverlo.
Suerte.

Anónimo dijo...

Suscribo la opinión de iván, lo sufro a diario eso y el ataque de usuarios corrosivos (jejeje que bueno el nombre) en una aplicación que estamos desarrollando para un ayuntamiento.

Un saludo y felicidades por el post.

erGuiri dijo...

El punto 7 está incompleto, la ultima frase no acaba

josé M. Aguilar dijo...

¡Gracias por avisar, erGuiri!

Tenías toda la razón, se me quedó la frase a medio cocinar; ya está cerrada. :-)

Anónimo dijo...

Que encima de soportar todo esto, para el resto de empleados (jefes incluidos) seamos los "frikis sin vida personal" a los que no les importa echar unas horitas de más para compensar todos los puntos de la lista a cambio, eso sí, de un par de cafés.

;)

Anónimo dijo...

A mi siempre me ha irritado mucho que al finalizar un proyecto, que ha sido un infierno para el equipo de desarrollo y ha salido un producto mediocre, como se ha facturado se lleguen a considerar "buenas prácticas" la forma de llevar el proyecto ¿?¿?¿?¿?

También muy irritantes el 7, el 2, el extra 3... y el 1, claro XD.

Isra dijo...

Extra 3. El "experto" en desarrollo de software.

Diosss como me fastidia esa! Y encima algún cliente exige costes y plazos acordes con esa concepción falsamente simple: "si esto es fácil, me lo puedes hacer en dos semanas, que tú eres muy bueno". Como lo odio!

Admin dijo...

Tenía una lista por ahí que amplía un poco la de Kevin. Ahí va:

- Especificaciones claras. Cuántas veces nos hemos enfrentado a proyectos con especificaciones ambiguas que han cambiado al final del proyecto?. El ejemplo más claro es una web cuyas dimensiones varían al verla el cliente (y esto suele pasar al final del proyecto).

- Cambios con cuentagotas. Si hay algo insoportable es que nos estén enviando cientos de emails cada 2 horas con cambios y errores sueltos. Organizarlos en una lista por prioridad, para poder ser atacados uno a uno ayuda bastante. Puede llegar un punto en el que no leamos los emails.

- Cambios en ficheros editables. PDFs están bien para briefings y presentaciones, pero las listas son preferibles en TXTs o Excel files.

- Separar la información para cada departamento. En un proyecto, pueden trabajar más de un programador, diseñadores, etc. cada uno en un departamento distinto. Mezclar los cambios en un solo email supone duplicar el trabajo a todos ellos.

- Responder a las preguntas de los programadores. Si no se sabe la respuesta o se necesita una aclaración, hacerla. Ignorarnos sólo retrasará más el proyecto.

- El número de cambios suele ser inversamente proporcional al número de bugs imprevistos que aparecerán. Lo normal es que al arreglar un bug, surjan otros que dependían de las variables modificadas.

- Consideren formar a sus empleados en técnicas simples, tales como subir un archivo, html básico (b, i, p, li y poco más), incluso edición de imágenes (recortar y exportar). Las ventajas son evidentes, al menos para nosotros y para la documentación, que no tendrá que explicar lo que debe considerarse de dominio público.

- Los sistemas operativos / navegadores no son cajas mágicas... tienen diferentes enfoques para los problemas, aunque en esencia hagan lo mismo. Por otro lado, internet tampoco es mágico, todo lo que contiene ha sido previamente programado por alguien. Comprender estos detalles por parte de los managers y clientes nos ayudará a realizar mejor nuestro trabajo.

Anónimo dijo...

Los puntos de.
Ampliación del ámbito y Imprecisiones es lo que mas me surra, eso de que no dicen explicitamente que va a ser y te pieden tiempos

:: Hacker :: dijo...

"Si esta faci, ademas el diseño no es la gran cosa"; Jaja, no te estoy cobrando el diseño!!!, sino la programacion wey!!!! :D

Anónimo dijo...

Buenismo...no es mas que la verdad :)

stormbringer dijo...

Les falta poner: "Que te pidan tiempos de desarrollo y al final el jefe decida cuanto se tiene que tardar cada face del proyecto"

@Lobosoft: si el jefe salia a las 3 am cuando programaba porque los que programan ahora no pueden, ...la novia y los hobbys personales solo quitan tiempo