Archivos Mensuales: noviembre 2013

Guerra de Browsers

Unos de los grandes problemas de los desarrolladores de aplicaciones web es la gran cantidad de browser que existen. Esto provoca que haya problemas de contabilidad tanto a nivel de diseño de la interfaz gráfica y de la programación a nivel de cliente. En otras palabras, lo que puede funcionar bien en un browser, puede no funcionar en otro. Además de los diferentes tipos de browsers, estos también tienen distintas versiones, lo que también provoca los mismos problemas de compatibilidad.

Lo triste de esto es que este tipo de problemas pueden traerse abajo un proyecto. Hace unos días terminamos una aplicación web que estábamos desarrollando en el trabajo. Su funcionalidad siempre fue probada en los browsers de Google Chrome y Mozilla Firefox y todo funcionaba perfecto. Sin embargo el problema comenzó cuando recordamos que la aplicación también debía ser funcional en Internet Explorer. Encontramos una gran cantidad de casos de uso que no funcionaban y tuvimos que investigar cuales eran las razones de este comportamiento. Gran parte de la aplicación funcionaba a través de javascript y descubrirnos que había ciertas funciones que el browser Internet Explorer no sabía interpretar a diferencia de Google Chrome y Mozilla. Nos dimos a la tarea de cambiar las funciones a una forma en que Explorer las pudiera interpretar y todo funciono a la perfección. Si bien tuvimos suerte de que no fue un retraso significativo, igual se perdió tiempo valioso investigando el problema y arreglándolo; tiempo que habíamos destinado para pruebas de la aplicación. La realidad es que si no hubiéramos podido dar con una solución, muy probablemente se hubiera traído el proyecto abajo, ya que uno de los requerimientos decía que la aplicación debía funcionar en Internet Explorer.

Hoy en día es muy difícil desarrollar una aplicación web con funcionalidad compleja para que funcione en todos los browser y todas sus diferentes versiones. Definir los browser indicados y las respectivas versiones bajo las cuales debe correr la aplicación, debe ser un punto importante en la definición de requerimientos no funcionales de un proyecto. Siempre debemos de recordar que la guerra entre los distintos browsers, puede traerse abajo un proyecto.

Análisis y diseño en el desarrollo de software

En octubre del 2013 estaba desarrollando una aplicación odontológica en el trabajo. Debida de crear una odontograma que pudiera representar todos los posibles tratamientos que ofrece un dentista, desde amalgamas, resinas, endodoncias, entre otros. Estebamos cortos de tiempo, por lo que el análisis y diseño del odontograma y sus tratamientos fue muy rápido y pobre. Fue cuando debíamos desarrollar la administración de todos los tratamientos, cuando los problemas empezaron. Tenía tres tipos de tratamientos, los que debían de dibujarse, los que no podían ser dibujados y eran para un diente en específico y los que eran para toda la boca y no podían ser dibujados.  A la mitad del desarrollo de los 3 administradores nos dimos cuenta que el código de la administración de los tratamientos era muy parecido. Queríamos hacer un refactoring al código que solucionaría todos nuestros problemas de diseño y dejaría el código mantenible, pero por el poco tiempo con el contábamos y con administradores a punto de terminarse, no nos arriesgamos ya que hubiéramos tenido que volver a probar todo.

El problema se agravó cuando fuimos a presentarle lo realizado al odontólogo. Este nos dijo que algunos de los tratamientos no eran implementados de la forma correcta, además muchos de los tratamientos tenían diferentes etapas o subprocesos.

Lo ideal acá hubiera sido hacer un alto, hacer un refactoring al diseño actual, tomando en cuenta los nuevos requerimientos; sin embargo nos pasó lo mismo que la primera vez y decidimos no arriesgarnos y desarrollamos los nuevos requerimientos sobre lo que ya teníamos. En conclusión, todo fue un gran caos. Una aplicación con un diseño difícil de entender, los métodos se nos confundían a cada rato, funcionalidad repetida hasta cinco veces y código poco mantenible y extendible. Además todas estas dificultades hicieron que nos pasáramos de la fecha de entrega.

 Al finalizar el proyecto, me tome un tiempo hacer retroalimentación, reflexionar sobre lo hecho, lo aprendido por supuesto los errores cometidos. Es por eso que logre sacar las siguientes conclusiones que me servirán de experiencia para futuros proyectos:

  • Aunque se cuente con poco tiempo de desarrollo, siempre se debe tomar el tiempo necesario para analizar los requerimientos. Se debe estar seguro de entender los requerimientos al 100%. En mi caso, yo los entendí como debía cuando fui a la segunda reunión con el cliente y ya tenía una gran parte de funcionalidad desarrollada. No se debe comenzar a desarrollar sin tener los requerimientos bien definidos y claros.
  • Un gran error que tuvimos fue no haber entendido como funcionaban los tratamientos de odontología y los conceptos que se usaban. Esto dificulto mucho el análisis de los requerimientos y que posteriormente afecto el diseño realizado. Siempre se debe entender al máximo el dominio del problema.
  • Es esencial tomarse el tiempo necesario para realizar un buen diseño de lo que se va a realizar. No es necesario hacer un diseño perfecto, pero al menos se debe velar por realizar uno aceptable, usando como parámetros la extensibilidad, mantenibilidad y entendibilidad.  Nunca se sabe cuándo nos pedirán nuevos requerimientos y o haya que cambiar algo, por lo que tener un buen diseño hará que esto sea más fácil.
  • Si haya se ha desarrollado gran parte de la funcionalidad y logramos identificar funcionalidad repetitiva o partes que de código que se pueden mejorar, lo idea es hacer un alto en el camino y hacer refactoring. No obstante, antes de hacer esto se deben de tomar en cuenta dos cosas: Proximidad de la fecha de entrega  y estar seguro que entender los requerimientos como se deben. Si la fecha de entrega está muy próxima  y la mayoría de las cosas funcionan bien, se debe posponer el refactoring hasta una fecha oportuna

Curva de aprendizaje en desarrollo de proyectos

En el 2011 tuve un proyecto grupal de universidad donde debíamos crear una aplicación de inventario de medicamentos y la íbamos a desarrollar en .NET.  A mitad del proyecto se nos ocurrió que la interfaz se desarrollara en WPF(Windows Presentation Fundation) en vez de Windows forms. Ninguno del grupo sabía cómo desarrollar interfaces en WPF, pero teníamos buen tiempo para aprender.  A dos semanas de finalizar el proyecto, los encargados de desarrollar la interfaz no la tenían lista. A dos días de finalizar el proyecto se logró terminar la interfaz. Luego tuvimos problemas en integrar la interfaz en WPF con el dll de la capa lógica de aplicación. Al final vimos que estábamos durando mucho en integrar, no avanzábamos como rápido y el tiempo se agotaba; por lo que se decidió  y rehacer toda la interfaz usando Windows forms. El re trabajo fue mayor y el proyecto no se terminó como se debía.

Esta historia me enseño que nunca se debe subestimar la curva de aprendizaje en un proyecto cuando se usa una herramienta nueva o que nadie del grupo conoce; y al contrario, es algo que se debe tener muy encuentra.

Mi recomendación es siempre ir por lo seguro, por lo que conocemos; en especial si el tiempo de entrega está muy próximo. Si se cuenta con buen tiempo para entregar el proyecto se  podría destinar ciertos días para aprender a usar la herramienta y al final de esos días determinar con el equipo de trabajo si la herramienta es fácil de usar, si vale la pena y si puede causar atrasos por el poco conocimiento.

Habrá ocasiones donde nos veremos obligados a tener que usar una herramienta o tecnología cual no conocemos, debido a que posee  cierta funcionalidad con la que no contamos. En casos así lo ideal sería contratar a una persona que sepa de la herramienta y así estaríamos evitando el proceso de curva de aprendizaje. Sin embargo, no siempre se puede contar con el dinero para esto, por lo que se debe analizar qué tan necesario o relevante es la funcionalidad que se requiere para el éxito del proyecto. He hecho un análisis con las mejores decisiones para este caso, no obstante cabe mencionar que el desarrollo y administración de proyectos  es un tema que contiene muchas variables  por lo que estas decisiones no son una metodología o una “fórmula mágica” para casos así, sin embargo pueden servir como base de análisis para sacar otra decisión que sea la más indicada.

  1. Asignar a uno o varios miembros del equipo para aprender a usar la tecnología y ponerle una fecha límite para esta curva de aprendizaje. Esta fecha límite debe calcularse teniendo en cuenta lo que pasaría si los miembros del equipo no logran adquirir el conocimiento requerido en ese tiempo.
  2. Si el tiempo que queda para entregar el proyecto es muy poco y la funcionalidad no es de alta prioridad, lo idea es terminar lo que falta primero y luego negociar con el cliente a ver si extienden la fecha de entrega para desarrollar lo que falta.  Es preferible terminar la esencia del proyecto a arriesgarlo por algo tal vez no tan relevante.
  3. Si todo el proyecto o las funcionalidades más importantes están basados en una herramienta o tecnología difícil de usar en la que ningún miembro del equipo tiene conocimiento alguno, pues están en el proyecto equivocado.