Los peores hábitos al desarrollar software

En donde estudié, la mayoría de los maestros son profesionistas y siempre decían algo como "el libro dice esto, pero allá afuera, es así...", y para ser honestos, el problema con los planes de estudios, es que son muy objetivos, y muchas veces siempre toman en cuenta que todo sigue un proceso linear, teóricamente optimizado, en donde no existen retrasos, cosa que se da con rareza en el mundo laboral. Lo anterior, aunado con la falta de sentido común que podemos llegar a demostrar, y poco interés por prevenir posibles contingencias,  son un receta para el desastre con el que lidiará el usuario final.

Descargar de Internet, sin antes averiguar si funcionará

Tristemente, cuando el tiempo se nos viene encima, podemos caer en la tentación de buscar en Internet, descargar, y es válido, pero hay que evaluar si realmente hace lo que se requiere; y no se necesita hacer alguna adaptación importante de código o agregar un proceso de compatibilidad.


Si se descarga de Internet, hay que tener en cuenta en dónde se va a implementar, muchas veces, no es gran problema implementar un sistema de PHP en un servidor de IIS en Windows, y viceversa con Linux y ASP ; pero cuando hablamos de herramientas como Moodle (sistema de cursos en línea), las cosas cambian, dado que requieren configuraciones específicas de componentes demasiado específicos, lo que hace un fastidio de implementar... afortunadamente, viene en un paquete XAMPP, convenientemente configurado, listo para descargar e implementar en distintos sistemas operativos con un par de clicks, aunque no siempre éste es el caso con todo el software...

No permitirse realizar la ingeniería de requisitos

Uno de los errores más graves que se pueden cometer es no hacer la ingeniería de requisitos, dado que a veces, el requerimiento puede parecer sencillo, pero al ir trabajando en la lógica de negocio (el cómo se interrelacionan los procesos), surgen detalles que fueron estimados como insignificantes, y al final del día resultaban ser de importancia.


Odio trabajar el doble, sin motivo, y supongo que no soy el único; tener que hacer varias veces el mismo sistema, no porque no funcione, sino porque no es lo que el usuario necesita; para que al final termine siendo usado un par de semanas, para ser dejado en el olvido, haciendo una pérdida de tiempo para todos, sin mencionar la mala impresión que ésto deja.

No pensar en el usuario final, al realizar el diseño de interfaz

A pesar de tener la buena intención de querer innovar con el diseño de la interfaz, muchas veces, se termina criando una repulsión de los usuarios, debido a,  la imposición, aparentemente arbitraria de procesos que complican lo que antes, se hacía de manera sencilla.


El ejemplo más claro es Microsoft Office, que al principio usaba una interfaz estándar de barras de herramientas hasta la versión 2007, para cambiar a la interfaz de tipo Cinta (Ribbon), que hasta entonces se usaba más en software de diseño.

Office 2003, con muy poca variación en la interfaz, desde su versión 6.0 para Windows 3.11, su ventaja principal era que dejaba personalizar las barras de herramientas.

 

Para los usuarios veteranos de Office, fue una abominación (incluyéndome, a la cuál nos tuvimos que adaptar), aunque honestamente, es más fácil de usar, una vez que te das cuenta que las opciones aparecen de acuerdo a lo seleccionado.

Mi consejo es, incluir en el diseño, algo con lo que el usuario esté familiarizado, para hacer la transición o implementación de sistemas sea lo menos traumante posible, aunque, claro,  nadie se quejará si al final, si las mejoras sobrepujan a la incomodidad que representan dichos cambios.

No agregar un módulo de estadísticas o exportación hacia Excel

No sé que tienen las dependencias de gobierno, que les encantan las estadísticas, y trabajar con Excel; literalmente, si no tiene alguna forma de interacción con Excel, ten por cierto que en un futuro cercano, será un requisito indispensable y, probablemente, una crítica por la falta de un componente tan básico.

El formato favorito para exportación con la mayoría de sistemas es CSV. Yo recomendaría tener siempre a la mano un módulo de escritura de archivos CSV, con delimitadores de Tabulación, Pipes (|) y comas, que son los más comunes cuando se requiere alguna forma de comunicación entre sistemas (como normalmente ocurre en aquí, en México).

En conclusión: si algo puede salir mal, ten de cierto que saldrá mal

Sin excepciones, siempre surge algo que retrasa el desarrollo de cualquier software, por lo menos en donde trabajo, y siempre termina afectando las fechas de entrega.

Para evitar en lo posible el estrés que causa el que se acerque la fecha de entrega y el proyecto, todavía no está finalizado;  siempre trata de dar un fecha aproximada más un par de semanas de tolerancia, y como dice mi jefe; "nunca entregues un viernes, siempre el lunes de la siguiente semana, en caso de que haya algo que corregir o pulir a último momento", que usualmente es un cambio arbitrario hecho por alguna autoridad...

Ésto no lo digo con ánimos de ser pesimista, y ni siquiera para implicar que haces un mal trabajo; pero siempre debes de tener en cuenta que a pesar te tus mejores intenciones o extrema planeación, no debes de descartar un plan B, en caso de que todo salga mal: En el peor de los casos, ya sabrás que hacer,  y si no, al menos sabrás que hacer en caso de que se presenten situaciones similares.

También te puede interesar:

Cinta (informática) 

Es la interfaz en la cuál se mos presentan los botones de comandos agrupados por similitud de funcionalidad, en pestañas, popularizado por Office 2007 y sus veriones posteriores....
https://es.wikipedia.org/wiki/Cinta_(inform%C3%A1tica)

10 Errores comunes en diseño de Aplicaciones Móviles por Kent Mundle

Errores comunes de diseño, administración y marketing relacionados con el desarrollo de aplicaciones móviles...
https://www.toptal.com/designers/mobile/los-10-errores-m%C3%A1s-comunes-en-dise%C3%B1o-de-aplicaciones-m%C3%B3viles/es

Ley de Murphy

Enunciado que implica que, si existe la mínima posibilidad de que algo pueda salir mal, independientemente de la situación, saldrá mal...

https://es.wikipedia.org/wiki/Ley_de_Murphy