¿Qué hace que un proyecto y su plataforma de desarrollo fracase?

Son cosas que todos sabemos pero que sigo viendo en muchos proyectos, algunos de ellos se han hecho bastante populares.

  1. Debe estar documentada. Es de perogrullo pero es una cosa que a ningún desarrollador le gusta hacer pero es lo primero que buscamos cuando estamos programando. Un API sin documentación no sirve de mucho. Ejemplos de bibliotecas que triunfan y tienen una gran documentación y puede que parte de su éxito sea justamente este detalle son PHP, QtJava.
  2. Compatibilidad a lo largo del tiempo. Un api de programación tiene que ser estable a lo largo del tiempo, si se empiezan a cambiar las interfaces de los métodos o funciones, se crean incompatibilidades binareas, etc esta biblioteca nos dará muchísimos quebraderos de cabeza. Lo que suelen hacer algunos fabricantes es que durante la versión mayor de una biblioteca se mantiene la compatibilidad y cuando se pasa a la siguiente versión mayor ya si que se puede añadir lo que se quiera porque se permite la incompatibilidad con la versión anterior.
  3. Debe facilitar la actualización. Cuando se crea una nueva versión se debería pensar en la forma de actualizar desde la versión anterior de manera que luego no existan problemas en las migraciones.
  4. No se pueden dejar funcionalidades a medias. Si empiezas un desarrollo y no lo terminas no puedes dejar la aplicación llena de partes de dicho desarrollo pero que en verdad no sirven de nada.
  5. El código fuente debe estar en inglés. Habrá gente que no le guste pero el idioma internacional para la tecnología es el inglés y es el que todos los desarrolladores suelen entender. Si tu código está en otro idioma estás cerrando puertas para que otros desarrolladores entren al proyecto.

Existen muchos más problemas asociados pero estos 5 me parecen fundamentales. En Openbravo me he encontrado estos y nos está afectando actualmente en varios proyectos en los que estoy metido en mi empresa.

Ante el primer problema y preguntando diréctamente cómo funciona tal método de una clase a desarrolladores de Openbravo, gente que lleva trabajando para la empresa Openbravo desde hace bastante tiempo y que están en el equipo de ingeniería la respuesta es – No lo se, yo pillo un ejemplo parecido que ya esté hecho y copio y pego. A la pregunta de si estaba documentado la respuesta era no y que en todo caso se iban a la propia definición en el código de la biblioteca.La culpa no es de ellos, la culpa es de que el que escribió las bibliotecas y herramientas que utilizan no las documentó y actualmente no hay ningún recurso en Openbravo para documentarlas.

El segundo caso me pasó cuando intentamos utilizar un informe que desarrollamos según las indicaciones del wiki de Openbravo, este informe funcioaba perfectamente en la versión 2.35 pero al intentar compilarlo en la versión 2.40 no funcionaba. El problema venía porque habían modificado unos atributos privados de la clase base  de la que heredaba la clase que lanzaba el informe. En verdad habían hecho bastante limpieza en esa clase y si a eso le añadimos que a los atributos no se accede mediante métodos públicos, una interfaz pública pues no tiraba. Lo suyo es que como se comenta más arriba se mantenga el api de todas las bibliotecas que se utilizan en el proyecto a lo largo del tiempo. Se podría refactorizar el código pero siempre que mantuvieras las interfaces de las clases, pero es que en muchos casos ni siquiera hay interfaces bien definidas.

El tercer caso me ha pasado al intentar actualizar Openbravo, se supone que Openbravo utiliza un fork propio de ddlutils para la manipulación de la información en la base de datos. Su actualizar de la 2.40beta  a la 2.40 funcionaba  a la perfección con la instalación de la 2.40beta limpia pero si intentaba aplicarlo sobre uno de nuestros proyectos me dió un error tan chorra como que un campo que no era único había pasado a ser único en una tabla y al detectar duplicados no podía terminar el proceso de actualización de la base de datos dejándola en un estado inconsistente. Este tipo de cambios no se deberían dar en una base de datos medianamente estable, pero si se dan y quieres hacerlos debes tener mucho cuidado de que no existan problemas al actualizar.

El cuarto caso es muy típico en Openbravo, la aplicación está plagada de campos, ventanas/pestañas que no sirven para nada pero que por alguna extraña razón alguien dejó ahí. Esto a parte de confundir al usuario da una sensación de dejadez impresionante. Aquí os dejo un ejemplo.

El quinto caso sigue ocurriendo en Openbravo, han ido limpiando muchas partes del código pasándolo al inglés pero todavía queda mucho trabajo por hacer, sigue habiendo mucho código en castellano.

¿Qué problemas soléis encontrar vosotros en los proyectos en los que estáis?

Cheli

Comentarios

  1. Moises

    Lo de el código en español me lo he encontrado en el 100% de los proyectos patrios en los que he podido meter cabeza y es algo que odio profundamente.

    Hay una cosa que ocurre en mi trabajo que llamo «el legado» y consiste en que, debido a una dejadez impresionante y una falta total de proyeccion y vision, cada uno de los programadores que ha pasado por aqui ha implementado su propia forma de hacer las cosas (cada una peor que la anterior, por supuesto). Asi que tenemos tres formas de acceso a datos, dos gestiones de sesiones, etc.

    Una puta mierda como una catedral, pero esa parece ser la forma de trabajar en este pais.

  2. Autor de la
    Entrada
    Cheli

    Eso si que no lo había visto Moises, eso si que es una putada.

    Otra que me dejé es una cosa que me da muchísima rabia, que no exista una guía de estilo para el código o que existiendo nadie la siga. En openbravo estoy acostumbrado a ver sentencias sql unas con las palabras reservadas en mayúsculas (SELECT, FROM, WHERE, etc) y otras todas en minúsculas por poner un ejemplo.

    Esto me molesta muchísimo y te hace perder mucho tiempo ya que una buena guía de estilo bien definida y llevada a cabo te deja un código mucho más legible.

  3. Moisés

    Y para solucionar eso no es tan fácil como crear una guía de estilos ?

    Es lo que intento hacer cada vez que en un proyecto interviene más de una persona.

    Por cierto, mira que es difícil encontrar a dos con el mismo nombre y me lo encuentro aquí 🙂

  4. Elman Rasasa

    Cheli,

    solo estas en el inicio de sus decepciones e de los gastos con el Openbravo. Aviso porque conozco lo caso (el fracaso debería decir) muy bien. Hay otros ERP’s de código abiertos mucho mejores (mas la próxima vez, procure una comunidad independiente que usa realmente el ERP e sabe de que habla), llegará mas rápido (mucho mas). Pensó que lo que explica que el código fuente de Openbravo tiene todos estos problemas detrás del aspecto falsamente «popular» e limpio de la empresa con mismo nombre es lo siguiente: Openbravo engañó un fondo de inversión el ano pasado criando el sueño que que empresas como Sun Microsystems podrían comprar Openbravo después, como acontecí con MySQL en el inicio de 2008. En otras cosas, Openbravo esconde las centenas de miles de liñas de código plSQL heredadas de Compiere, una tecnología muy retrasada e no compatible con MySQL, detrás de la palabra mágica ‘Java’ (e dentro de XML CDATA). También hace como que (me gustaría saber como exactamente…) que algunos blogs propagan este «hype», por ejemplo: http://www.thevarguy.com/2008/08/07/openbravo-mysql-killer-open-source-combo-coming-soon/ ou http://opensourceerpguru.com/2008/09/26/openbravo-network-edition-it-rocks/

    No solo el fondo de inversión ha sido engañado, mas también muchos «partners» a cerca del mundo (puede me decir cuales de ellos reivindican alguna «success story» con esta mierda de ERP?). Ahora Openbravo continua investir mucho dinero para engañar empresas como la de usted con lo mismo discurso marketting que siempre usa. Mas no basta, espero que abre los ojos antes de perder mucho tiempo e dinero: un código como este no se puede mejorar, hay que dejar lo para empezar un nuevo. Mejor no ser la víctima que pagara la cuenta. Otros están dejando el barco Openbravo: http://obtrainings.es/2008/10/23/despedida/ antes que hunda.

    Elman Rasasa.

  5. Dario

    Creo que en este caso, los «otros» no son tales 😉

    Aprovecho para saludar al autor de este y el otro blog, lo sigo siempre. Lamento profundamente que haya discontinuado Obtrainings, pero es perfectamente comprensible que así haya sido.

    Saludos,

Deja un comentario

Tu dirección de correo electrónico no será publicada. Los campos obligatorios están marcados con *

Este sitio usa Akismet para reducir el spam. Aprende cómo se procesan los datos de tus comentarios.