This article provides some thoughts about to treat the software development activity more related as an art (or even gardening) than a science. The title means something like "Software Gardening". This article was published by the investor's magazine IGDigital.com and tech magazine RedUsers.com.

1. Jardinería de Software
En los últimos meses, un tema se viene entrometiendo en las conversaciones que
mantenemos con Alejandro Siri de Quanbit sobre los resultados finales de cada proceso
de desarrollo de productos de software: un concepto denominado “Jardinería de Software”
que se contrapone a la idea de “Ingeniería de Software”.
Es cotidiano comprobar que en cada situación en la que se le presenta una pieza de
software recientemente terminada a la persona que ideó la pieza o producto, nacen de
manera explosiva una incontable cantidad de nuevas ideas:
1. ideas de mejoras a la pieza,
2. ideas para interrelacionar o combinar esa pieza con otras, y
3. disparadores de ideas laterales no vinculadas directamente a la pieza original.
Estos desencadenantes de ideas, son sin duda un avance hacia el fin último: lograr
implementación de la mejor idea posible. Además, cada nueva idea suele ser superadora
respecto de la anterior. Este es un proceso dinámico muy ligado a la conducta humana en
la que, de forma iterativa e incremental, se va logrando una maduración de la idea.
Nuestra expectativa es que la implementación tecnológica vaya acompañando a esa
maduración.
Pero la Ingeniería de Software tradicional propone una metodología de abordaje a la
construcción de software que consiste básicamente en: definir la idea completa desde el
principio, analizarla, diseñarla, implementarla y testearla, priorizando lospasos del
proceso antes que la dinámica creativa de las personas.
El proceso ingenieril puede ser técnicamente excelente aún cuando se implemente una
idea que se volvió obsoleta luego de ser diseñada. Agrega previsibilidad en tiempo y forma
aún cuando la implementación de una “función del software” carezca de sentido.
El software suele valorarse por su utilidad en la implementación de una idea o concepto.
Pero para poder implementar una idea que sufre una evolución continua, es necesario
adoptar una metodología de construcción de software que permita incorporar
al cambio como un elemento más del desarrollo. Para poder lograr un software útil, es
necesario de priorizar a las personas y sus cambios por sobre
losplanes y procesos. Este enfoque es la base de las nuevas tendencias en materia de
metodologías de construcción de software: las Metodologías Ágiles.
Es sabido que las Metodologías Ágiles ayudan a crear un software que implementa la
mejor de las ideas posibles o la más perfeccionada, pero agregan incertidumbre para
prever cuales, cuantas y cómo serán las funcionalidades a implementar… las respuestas
aparecerán a lo largo del proyecto de desarrollo.
Siendo muy creativos con la siguiente analogía, podríamos pensar que al comienzo de un
proyecto de desarrollo de software con Metodologías Ágiles solo contamos con una semilla
(la idea) que nos da una noción del resultado final en base a las características de la
especie a la que pertenece. Que si la plantamos y la regamos con un mix de creatividad,
diseño, herramientas y programación, lograremos con el tiempo hacer crecer la planta

2. (software) que buscábamos. Lo curioso es que si el día de la plantación tuviéramos que
describir cómo será exactamente esa planta cuando esté crecida, no podríamos saberlo, al
menos no más allá de sus rasgos generales. Quizá podríamos estimar cuanto tiempo
necesita para crecer, pero no podríamos predecirlo. Quizá podríamos prever que va a
tener hojas verdes y ramas, pero no cuantas ni de qué tamaño exacto será cada una.
En definitiva, a la hora de construir software con Metodologías Ágiles, nos encontramos
con que el proceso se asemeja más al de un trabajo de Jardinería que al de un trabajo de
Ingeniería. Obviamente es un punto de vista gracioso pero tiene muchos disparadores que
sirven para hacernos reflexionar cada vez que estamos en una conversación con alguien
que piense que la construcción de software es un proceso exacto, previsible o
estructurado.
Mientras tanto, podemos divertirnos (a nuestra manera) jugando con el nombre.