Jummp’s Blog

Todo lo que sea huir de métodos artesanales en los procesos de desarrollo de software supone tiempo y dinero o lo que es lo mismo dinero y dinero.

1) Intenta que todos los desarrollos de la empresa sigan un mismo framework siempre que sea posible (en ocasiones las imposición de una determinada arquitectura o tecnología por el cliente lo impide, pero en el resto de casos, siempre que se pueda, haz uso del framework). El framework además es recomendable que esté recogido en un libro blanco de desarrollo (que va más allá del framework, lógicamente) y mantener ese libro blanco actualizado. Este framework único facilita la movilidad de los programadores entre proyectos y la mantenibilidad de los sistemas. No tengas miedo en actualizar el framework o el libro blanco, si aparece o encuentras alguna librería, componente, arquitectura, etc… mejor que la que usas, más estable, más robusta y/o que te permite una mayor productividad no dudes en cambiar el framework, eso sí, debe hacerse con prudencia y con un espacio de tiempo razonable entre cambio y cambio.

2) Intenta que el framework se base en estándares.

3) Si además del framework base, se tienen componentes software concretos y completos que resuelven problemáticas cada uno de ellos en diferentes tipos de proyectos, mejor que mejor.

4) Si se tienen productos completos que simplemente requieren su personalización en función del cliente, todavía mejor.

5) Siempre se habla de reutilizar código, pero si se consiguen reutilizar requisitos de proyectos o lo que es lo mismo la experiencia, también resulta de gran importancia. Para esto hay que documentar y establecer mecanismos que permitan localizar en la documentación de proyectos lo que se quiere y de esta forma obtener conocimiento.

6) La documentación de los proyectos queda obsoleta por la evolución de los mismos y resulta muy costosa mantenerla, por lo tanto, lo mejor es tener poca documentación pero buena y mantenerla actualizada. Por otro lado, toda aquella documentación que se pueda automatizar bienvenida sea y toda aquella documentación que se pueda sustituir mediante la aplicación de ingeniería inversa sobre cualquiera de los elementos del programa, sustitúyase.

7) Si existe software de gestión de versiones, MAVEN y herramientas software para definir entornos de integración continua, utilícense. Eso sí, bien. De nada te vale tener los fuentes en SVN si no tienes una buena política de etiquetado, de nada te vale usar MAVEN si no estrujas su potencial para automatizarte tareas, etc…

Independientemente de que se definan buenas prácticas hay que verificar que se siguen. Si puedes ten uno o más arquitectos que vayan sondeando el estado tecnológico de cada proyecto.

9) Ten documentado como es el proceso de implantación de software en tus clientes, permitirá ahorrar mucho tiempo.

10) Nunca es una pérdida de tiempo cada minuto que dediques a probar la aplicación antes de entregarla al cliente.

La piedra filosofal de la construcción de software es la generación automática de código evitando cualquier tarea mecánica o repetitiva que tenga que realizar un programador. Si el generador de código está bien construido y depurado, el software saliente se encontrará libre de errores (y, ¿por qué no? tendrá gran calidad) y además hará más sencillo la verificación por parte de toda la organización de un framework de desarrollo común.

Un buen generador de código reduce considerablemente por tanto los tiempos de desarrollo, incrementa la calidad del resultado final y como consecuencia de ambos aspectos reduce los costes de producción.

Los generadores de código siempre han tenido la crítica (la tienen los frameworks en general) de aplicar soluciones muy generalistas a problemas concretos o lo que, dicho con otras palabras, no aplicaba soluciones tan eficientes como desarrollos realizados de forma específica. Sobre esto habría mucho que comentar y debatir. Mi opinión al respecto es que es tan bueno lo que aporta un determinado framework o un buen framework de generación de código que no debe haber lugar a debate, ya que todo lo positivo que proporcionan desnivelan considerablemente la balanza a su favor.

Evidentemente el éxito de una empresa de desarrollo de software no es sólo su framework o la disponibilidad de una buena herramienta de generación de código, ya que los proyectos de desarrollo de software requieren de muchos aspectos más para tener éxito, como por ejemplo un buen análisis (fundamental para cualquier solución de generación de código, ya sea orientada a modelo o aplicando otra estrategia), una buena gestión interna y con el cliente del proyecto, un buena ejecución final de la lógica de negocio y de la capa de cliente, un importe de venta del proyecto acorde a su naturaleza y complejidad, etc, etc, etc…

En cualquier caso, quienes posean una buena solución de generación de código, si la saben explotar convenientemente y siguen invirtiendo en ella, tienen una ventaja competitiva importante respecto a los demás.

Es cierto que mi experiencia en el mundo laboral es relativamente corta y que el desarrollo de software es todo un universo por descubrir, pero todavía no he descubierto el secreto del framework de la corbata, esa alquimia que utilizan muchas empresas para producir software y que debe proceder de incunables que van de mano en mano y que contienen los secretos que hacen que se programe mejor haciendo que los empleados piquen código con chaqueta y corbata.

Fuera de ironías, ni entiendo, ni conseguiré entender por qué determinadas empresas hacen ir a los programadores (incluso siendo becarios o similares) a ir en traje y corbata a programar (quítese programar, por otros servicios TIC similares), incluso cuando no están en cliente y trabajan en las dependencias de su organización. Puedo incluso llegar a entenderlo si tienen que trabajar en cliente (aunque no compartirlo), sobre todo si en el cliente todo el mundo va en traje y corbata, también puedo entender incluso que los analistas, cuando vayan al cliente vayan también trajeados y también lo puedo entender en jefes de proyecto, gerentes, etc… ya que ellos pisan mucho cliente, pero por favor, que les hagan programar en la sede de la empresa vestidos así, no lo entiendo.

En mi opinión cuanto más cómodo esté la persona que realiza tareas de programación (y análisis) mejor va a realizar su trabajo y por mucho que se esté acostumbrado al traje y la corbata no es lo mismo que una camisa o una camiseta con unos vaqueros (además del ahorro de tiempo que supone cada mañana al levantarse). Soy consciente de que muchas empresas intentan trasladar de esta manera una imagen y que ese es el motivo, y eso puedo respetarlo, pero bien podrían intentar ser más flexibles en según que casos y no mostrar una inflexibilidad fuera de toda lógica.

De la última migración de versión del sistema de gestión de base de datos utilizado en mi organización, he sacado varias conclusiones:

- Los desarrollos de nuestra organización deben tender a una sola tecnología.

En mi organización ya decidimos hace tiempo que esa tecnología era Java, por lo que el camino ya está iniciado, no obstante, debemos comenzar cuanto antes la migración de todo lo que no está en Java a esa tecnología.

- Los desarrollos de nuestra organización deben tender a un solo framework.

En mi organización se ha están sentando las bases para que todos los desarrollos sigan un mismo marco, de ahí el libro blanco que rige los desarrollos, el cual está en pleno y continuo proceso de evolución.

- El framework debe ser lo más cerrado posible.

También estamos sentando las bases para conseguir esto, ya que las evoluciones del libro blanco van encaminadas a acotar este framework cada vez más. Evidentemente la evolución de la tecnología va a provocar que con el paso del tiempo haya aspectos que varíen en el framework de desarrollo, pero evidentemente será una situación mucho más aceptable que tener muchos proyectos desarrollados en tecnología Java, siguiendo estrategias distintas.

Es fundamental para la mantenibilidad de las aplicaciones (además de que estén bien documentadas y exista una correcta gestión de la configuración) que en la medida de lo posible, las soluciones técnicas sean lo más parecidas que se pueda. Desde mi punto de vista, la consecución de este objetivo tendrá un ahorro de costes importante a medio plazo.

He tenido la oportunidad de leer mucho últimamente sobre las factorías de software. Mi opinión sobre la producción industrializada de software, la podéis consultar en este mismo blog en una serie de artículos que dediqué al tema.

Como comentaba en dichos artículos, para mi la producción industrializada de software no existe, simplemente lo que se ha hecho es aplicar una serie de buenas prácticas (en algunos centros) y aplicar una serie de fórmulas para reducir en la medida de lo posible los costes de desarrollo (casi todas ellas basadas en la búsqueda de soluciones que impliquen un menor coste por mano de obra y el apoyo de las instituciones).

Los lectores de mi blog, también saben de mi opinión sobre el mercado TIC y en los últimos tiempos, también he tenido la oportunidad de comprobar que no me equivocaba. En esta época de crisis, las empresas de desarrollo de software van a por todas, utilizando unas políticas muy agresivas de precios.

Si las cosas no cambian o se está muy bien posicionado en el negocio o esto será la ley de la selva, donde sólo los más fuertes sobrevivirán (y aquellos aliados de los más fuertes). No todas las empresas pueden asumir esa guerra de precios sin una pérdida considerable de la calidad de los servicios que se ofrecen. Por este motivo yo que siempre he tenido un gran recelo de las factorías de software, veo que en las circunstancias actuales las empresas que tienen este tipo de recursos están bien posicionadas (siempre y cuando las factorías estén bien gestionadas) para poder competir.

Cuando se habla de factorías de software, se utilizan a menudos los términos Nearshore y Offshore. El primer caso se corresponde a aquellas factorías que se encuentran próximas geográficamente (o que tienen algún rasgo común, como por ejemplo, una franja horaria próxima, el idioma, etc…) a las organizaciones para la cual prestan sus servicios (en algunos casos proyectos concretos, en otros casos outsourcing), el segundo caso se corresponde a factorías más alejadas geográficamente y que en la mayoría de los casos no presenta rasgos comunes con las organizaciones a la que prestan servicio. Como habréis podido ver, existirán casos donde las factorías se puedan considerar Nearshore u Offshore en función de la persona que la defina.

Por regla general, se suele relacionar el Nearshore con soluciones de mayor calidad (y con un mayor coste de producción) y el Offshore con soluciones de menor calidad (y con un menor coste de producción). También hay que tener en cuenta que el Offshore en muchos casos es bastante complicado. Supongamos que situamos una factoría de software en Laos y que a ella desviamos carga de trabajo de programación. Si el análisis funcional está hecho en español, existirán serias dificultades para su interpretación por parte de los programadores del centro.

También hay quien utiliza el término de Inshore, para referirse a factorías de software situadas muy próximas geográficamente (100 kilómetros como mucho) de las organizaciones a las que prestan servicio.

En cualquier caso: Inshore, Nearshore y Offshore, lo importante es que el centro esté bien gestionado, que se utilice un framework de desarrollo común (y que pueda ser lo suficientemente flexible para poder adaptarse en situaciones concretas a especificaciones técnicas de clientes concretos) y que el personal que trabaja en los mismos esté lo más formado posible (y existan unos procesos de formación continua). De esta manera más o menos la calidad de los productos no debería ser tan significativa, ni ser tan distintas (aunque la barrera del idioma, en muchos casos, puede afectar notablemente el resultado del producto). Si la gestión es buena, el framework es común y flexible y se poseen buenos técnicos, los costes de producción se reducirán, dejando prácticamente como aspecto diferencial el nivel adquisitivo de los países donde se encuentre la factoría de software, lo que permitiría pagar sueldos más bajos y por tanto permitir ofertar en los proyectos un mayor número de horas a un menor coste.

Aunque la solución que más me guste sea la Inshore o en su defecto la Nearshore, más que nada porque no me gusta por qué se realiza la deslocalización, ni que se aproveche el nivel de vida de un país para ofrecer salarios varias veces más reducidos que los de nuestro país, no tengo más remedio que reconocer que quien posea la infraestructura y la organización para ofrecer productos con un nivel de calidad aceptable y a unos precios rompedores, tienen todas la de ganar en un mercado tan competitivo como es el del desarrollo de software.

¿En cuántos proyectos en los que ha participado o desarrollado tu organización habéis empezado desde cero, es decir, desde el framework (si es que hay framework)?.

Si se tiende a cero, mala cosa, por muy potente o poderoso que sea el framework.

Me pongo a analizar algunas empresas desarrolladoras de software de éxito, sobre todo alguna emergente en los últimos años y no me canso de ver el mismo producto base revendido hasta la saciedad o bien adaptaciones del mismo (sin ser productos excepcionales, ni novedosos). Por muy baratos que los vendan (que además no siempre se venden baratos), el beneficio es prácticamente íntegro.

Hay muchos proyectos que por necesidades del cliente sí que se tienen que hacer desde cero e incluso con variaciones en el framework si así lo estiman las normas de desarrollo del cliente. En esto no entro. Sí que entro en otros proyectos donde el cliente tenga unas normas de desarrollo más relajadas y lo que le interese sea obtener un producto que colme sus necesidades, con un precio y plazo de ejecución razonable.

Salvo proyectos muy específicos, en la mayoría de los casos siempre hay partes que se pueden reutilizar de un proyecto a otro. En muchos posts he hablado ya no solo de la necesidad de disponer de un framework lo más potente posible, sino de disponer de un catálogo de componentes de más alto nivel reutilizables. En este post voy más allá, existirán proyectos donde lo que se puede reutilizar es la misma aplicación en sí, variando lo que se tenga que cambiar en la capa cliente (ya sabemos todos que simplemente cambiando la capa cliente una misma aplicación puede parecer otro totalmente distinta aunque la funcionalidad sea la misma) y en la capa de negocio o de acceso a datos. Para que un analista pueda hacer eso, necesita tener un conocimiento general de las aplicaciones que se desarrollan en la casa. Es por esto (aunque el objetivo no sea enseñar los productos para que se reutilicen) por lo que muchas empresas, de vez en cuando (una vez cada cuatro meses o semestralmente), hacen unas jornadas de divulgación entre los empleados, enseñándole a los mismos los proyectos más significativos que han terminado su ejecución en ese período o que están a punto de terminar.

También es cierto que es más complicado reutilizar cuando eres agente pasivo en una contratación, es decir, ganas un concurso (con esto no quiero decir que no se pueda reutilizar, pero digamos que la iniciativa, la lleva como es lógico el que contrata y te puede poner una serie de restricciones en el proyecto que te impidan en gran medida la reutilización), pero es más sencillo si eres agente activo, es decir, tienes un software que resuelve una temática concreta de un negocio y lo vendes a un tercero. Eso sí, en el acuerdo de venta debe quedar muy claro, hasta donde va a llegar la personalización, ya que en caso contrario, te puedes encontrar con que te desvistan entero el producto y sea lo mismo que empezar desde cero.

Tanto si tienes externalizadas las tareas de programación, como si no o tu empresa se dedica al desarrollo de software, resulta esencial la existencia de un libro blanco de desarrollo que marque una línea tecnológica y de arquitectura para los sistemas de información.

De esta forma el desarrollo de los proyectos es homogéneo y facilita las tareas de mantenimiento. Además, supone un ahorro de costes, ya que el desarrollo bajo un paraguas común facilita la existencia de un framework y de una colección de componentes estable.

El libro blanco de desarrollo supone también una métrica cualitativa de medida de la calidad de los desarrollos en cuento a lo que a tecnología y arquitectura se refiere, algo que resulta fundamental.

El libro blanco de desarrollo debe centrarse en la selección de buenas prácticas, tecnologías, patrones y arquitecturas para el desarrollo de software para cada uno de los paradigmas de sistemas de información en los que se desarrolle. El libro blanco debe marcar un camino y digo camino y no línea, ya que es recomendable ser flexible para determinadas soluciones, dando la posibilidad de utilizar distintas alternativas. Además debe huir de soluciones “propietarias” (en el sentido de que sean soluciones particulares de una empresa en cuestión) a nivel de framework y adoptar componentes que resuelvan problemáticas funcionales recurrentes sean o no “propietarios” en el sentido indicado anteriormente.

Evidentemente si trabajas en una empresa de desarrollo de software debes desarrollar según las directrices tecnológicas que te marque el cliente, pero en el caso de desarrollos internos, desarrollos I+D o desarrollos para clientes que no te marquen una directriz tecnológica sí que resulta muy interesante el uso de un libro blanco de desarrollo.

Otros aspectos importantes que debe cubrir un libro blanco debe ser la organización del software y el procedimiento de entregas, es decir, qué sistema de control de versiones utilizar, cómo utilizarlo, cuál debe ser la política de etiquetado, qué solución utilizar para automatizar la realización de pruebas unitarias, despliegues, cuál es la política a seguir para el paso a pruebas y/o producción del sistema, etc…

Como se puede apreciar, un libro blanco de desarrollo bien hecho, no está al alcance de cualquiera, de hecho se escapa, en mi caso, varios millones de leguas de mi capacidad técnica. La persona o personas que lo realicen deben tener un gran conocimiento de arquitecturas y tecnologías software, estar muy al día de todas ellas y tener una gran experiencia en el desarrollo y gestión de proyectos de desarrollo de software.

Desde hace unos pocos años está muy de moda el concepto de producción industrializada de software, queriendo dar una semejanza entre los procesos industriales de fabricación de coches, lavadoras, ordenadores, etc… y el proceso de desarrollo de software.

El concepto de producción industrializada aplicada al software es relativamente reciente, aunque se viene aplicando en las empresas de desarrollo de software desde prácticamente los inicios de la programación y se ha visto reforzado en los últimos años con la aparición de potentes frameworks de desarrollo, potenciados por las distintas empresas para reducir los costes de desarrollo y la programación aplicando patrones de diseño y la reutilización de componentes de análisis, software y documentales.

Es decir, las empresas desarrolladoras de software siempre van a intentar reducir los tiempos de desarrollo, aplicando algunos conceptos de lo que es la producción industrial. No obstante, en el software hay que tener en cuenta que en la mayoría de los casos se trata de un desarrollo a medida, lo que provoca que soluciones software parecidas tengan un enfoque distinto en función del cliente que la ha encargado. Esto rompe el concepto de producción industrial y nos dirige a un proceso más realista como es el del desarrollo moderno de software basado en arquitecturas que utilizan patrones de diseño, un framework de base y un catálogo de componentes.

En mis posts, pasados y futuros, haré muchas menciones a la necesidad de tener frameworks de desarrollo que ahorren toda la codificación que sea posible y además que sean estables, de calidad (con el menor número de errores posibles) y basados en productos estándars y libres por un lado y componentes de más alto nivel desarrollados por tu propia empresa haciendo uso también de librerías primitivas estándars y libres. En la fortaleza de ese framework depende en gran medida la reducción de los costes de producción de software sin necesidad de perder calidad.

Pues bien, hay otro elemento importantísimo que eleva el nivel de todos los frameworks que tengas implantados en tu empresa: la comunicación.

La comunicación interna, entre el equipo de jefes de proyecto, analistas y programadores, para repartirse el trabajo coherentemente, para preguntar cualquier duda sobre el análisis, la arquitectura o la codificación y la comunicación con el cliente que es el que te tiene que suministrar las especificaciones funcionales y no funcionales del producto, el que te tiene que dar el visto bueno final y con el que tienes que pactar los plazos de entrega y otros plazos intermedios (para entregar documentación, ver prototipos, etc…). Tan importante es alimentar el framework de desarrollo como utilizar de base una buena política de comunicación.

Ya he hablado muchas veces de los frameworks de desarrollo, desde lo que son las piezas base del mismo, hasta llegar al nivel de componentes reutilizables (de alto y bajo nivel en función del proyecto), pasando por la selección de una arquitectura óptima para el proceso de desarrollo.

Todo lo anterior ahorra costes de desarrollo y si el framework es estable, pues también asegura un número de errores mínimo provocado por los mismos, por lo que también supone una buena base para la calidad de la entrega.

En este post, hablo de ir a más, de crear componentes software a nivel de aplicación, diseñado de tal forma que con una parametrización de la misma pueda ser implantada en diferentes organizaciones. Lo de la parametrización es lo óptimo, sé que no siempre se puede llegar a ese punto, pero por lo menos se debe lograr que esas piezas completas de software se puedan adaptar a una organización aplicando los menores cambios posibles sobre su código.

Diseñar software así no es sencillo, pero tener un catálogo de productos software disponibles para su instalación y parametrización supone unos beneficios en cada venta muy considerables, además de situarte frente a tus competidores en una situación privilegiada.