Metodologías de Desarrollo de Software (Parte 1)

Guillermo de Ockham

William de Ockham (El de la famosa navaja) pensaba que el ser humano organiza su pensamiento diseccionando los conceptos para poder entenderlos mejor, “Diseccionar para analizar”, y es así como logra formar una perspectiva importante al rededor de las ideas lunares de Platón resolviendo el problema epistemológico donde los conceptos tienden a ser mayores que los objetos que representan debido a la abstracción y la herencia de características según la clase de los conceptos que los engloban sucesivamente.

Esta teoría explica muchos paradigmas utilizados en la computación y el desarrollo de software; desde los flujos lógicos lineales y no lineales (como prolog), el paradigma de orientación a objetos, la mayoría de los patrones de diseño, los repositorios de módulos ó sistema de instalación de paquetes y finalmente arquitectura de software y manejo de proyectos.

Los 2 últimos tratan siempre de resolver la mejor manera de construir un pedazo de software que deje totalmente satisfecho a quien lo solicitó en primer lugar, utilizando un presupuesto que genere un beneficio económico considerable en cuanto al costo que el que aprueba el presupuesto espera y que satisfaga una necesidad real a quienes lo van a usar sin que tengan que adquirir nuevos conocimientos y habilidades, peder tiempo en tareas no previstas o enredarse en una telaraña burocrática sin sentido que adora a los procesos cual deidad medieval dejando a un lado a las personas que fluyen en los mismos.

En lo que va del año he leído un par de artículos que manejan el concepto de “jardinería de software”. Aunque siempre mantengo un punto de vista escéptico  cuando se trata de nuevos paradigmas, siempre procuro aprovechar la flexibilidad que me otorgan las disciplinas en las que me especializo para tomar un riesgo medido y así procurar estar a la vanguardia en innovación; así que empecé a analizar el paradigma jardinero contrapunteándolo con el albañil.

Mi primera, y superficial debo decir,  observación, es que el paradigma que compara al código con las plantas denota mucha frustración de parte de sus promotores. Frustración en cuanto a los sistemas rígidos con los que se acostumbraba manejar la arquitectura y los proyectos. Es decir que en las comparativas que he encontrado que evocan este nuevo paradigma siempre aparecen frustración del cliente, malos productos entregados, ignorancia del usuario final y falta de dinero; y estas no son resultados inalienables a las metodologías de la vieja escuela.

Lo segundo que noto es que la mayoría de los involucrados en esta reciente evangelización son personas que llevan relativamente poco dedicándose al desarrollo de software. Algunos de estos autores recién empiezan a utilizar metodologías ágiles y posiblemente todos se hayan encontrado, por lo menos en una ocasión bajo el yugo de algún cliente, jefe o proveedor con un pésimo manejo de arquitectura y proyectos que parecía saber utilizar métodos RUP, PMI e ITIL a la perfección (De este tipo especial de especímenes hablaré más adelante en este blog)

Luego entonces. Si hacemos un análisis superficial y puramente emotivo respecto al paradigma de jardinería de software basándonos en los precarios escritos de unos cuantos, lo más posible es que el veredicto sea que estamos totalmente a favor de este nuevo paradigma. Pero como lo mencioné anteriormente, soy un escéptico, así que me di a la tarea de analizar racionalmente y apegándome lo más posible a métodos científicos este paradigma.

Debido a que mi especialización en el desarrollo de software se limita a tecnologías orientadas al usuario final y, aunque he desarrollado software b2b y administrativo, podríamos decir que el 80% de mi expertise es en está disciplina. Así que abordaré este análisis tomando en cuenta sólo proyectos de desarrollo a usuario final.

Por lo anterior lo primero a descartar es cualquier conclusión que no aplique al desarrollo web; así que no podremos aseverar que los procesos de la vieja escuela funcionan o no para desarrollo que no sea para usuario final.

Empezaré por describir la metodología que he utilizado en casi todos los últimos proyectos que he dirigido, los cuales han sido separados en las típicas 2 capas: Front-end y Back-end.Para esta descripción me gustaría utilizar el ejemplo de la construcción del Eurotunnel.

El Eurotunnel fue construido haciendo 2 grandes excavaciones, una desde Inglaterra y la otra desde Francia, ambas dirigidas hacia el mismo punto, ambas excavaciones hechas por equipos distintos, con culturas distintas y que se comunicaban en lenguas distintas (Sin mencionar las diferencias abismales en los gustos culinarios). Una vez que ambos equipos terminaron su trabajo se encontraron felizmente en el medio de ambas excavaciones. Cuentan las malas lenguas que hubo una diferencia de un metro para que ambos túneles encajaran perfectamente, que se solucionó fácilmente y que no se nota debido a que el agujero va forrado por varias capas interiores además del concreto que garantiza la rectitud del camino.

From France to England
How the Eurotunnel was builded

 

Continuará…

Comments are closed.