Las 10 cosas que mas fastidian a los programadores

Me ha llegado un correo de un excompi de trabajo de una traducción de un artículo que cita 10 de las cosas que mas nos fastidian a los programadores. Me ha parecido muy cierto y contado de una manera muy divertida, mi favorito es el punto 8, aquí  una copia de la traducción y abajo un enlace.

• 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.

Fuente: http://www.variablenotfound.com/2008/10/las-10-cosas-que-ms-fastidian-los.html