Hola a todos,
Vicente, creo que el tema de tratar de "nombrar" o "etiquetar" al desarrollo de software es algo muy relevante, bastante mas de lo que pudiéramos a lo mejor pensar a primera vista. Sobre todo, partiendo de la base del propósito de este grupo, de ayudar a "reducir el sufrimiento", dicen por ahí, que "No se puede dar lo que no se tiene...", así que si como "gremio" los programadores nos la pasamos mal viajados y protestando por todo lo que nos parece mal, es poco probable que tengamos espacio mental para poder ayudar a los demás, a lo mucho a lo que llegaremos es a desear que nuestra propia situación mejore.
Lo que he encontrado es que la mayoría del "sufrimiento" de los programadores en general se debe a que a nivel industria andamos todavía buscando una "metáfora" que aplique para describir lo que hacemos, aquello que elegimos como carrera. Actualmente, hay una tendencia en todos lados a ver al desarrollo de software como una "Ingeniería de Software", por lo tanto mas cercano a la técnica que a la ciencia o el arte. Un parámetro básico del método científico es tratar de comprobar una "hipótesis", ya sea a través de un experimento científico o de una demostración lógica o matemática, cosa que no aplica del todo a nuestro trabajo. Por el otro lado, de primera instancia, cuando hablas con un Gerente de Desarrollo de software, rápidamente te das cuenta que lo que menos quieren es un "Programador Artista" o la "Diva", se les percibe como un riesgo mas que una ventaja para el desarrollo de software.
Desde el punto de vista de Lean Software Development, se tiene un concepto, mucho mejor, el que el desarrollo de software es mas parecido al "Desarrollo de Nuevos Productos" que al de un proceso de manufactura, esto ayuda muchisimo para que la gente no técnica entienda y tenga una expectativa clara de que esperar de un equipo de desarrollo, un proceso de aprendizaje y descubrimiento cíclico. Introducir esta "metafora" por si sola en niveles de gerencia tiene un impacto concreto e instantáneo en mejorar las condiciones del equipo, los gerentes al fin "comprenden" que no nos tiene que meter en metodologías que solo producen estres y perdida de tiempo. Es una metáfora que a nivel organizacional definitivamente nos ayuda, hay que promoverla.
Sin embargo, esta metáfora de desarrollo de nuevos productos, nos deja a nivel personal, un poco desorientados, ¿Qué somos, científicos, técnicos, artistas o "mercadologos"?. La mejor respuesta que he conocido es la de los Pragmatic Programmers, que dicen, el desarrollador de software es un "Artesano". Imagino entonces al bisabuelo de mi esposa, ebanista profesional, una persona que hacia muebles de muy buena calidad y una maestría inigualable, como todos los artesanos de su época. Para ser un maestro artesano, hay que ser un poco científico, entender el proceso de la madera, su secado, la física y la química, aunque sea de forma empírica que afecta la construcción de los muebles. Así mismo, se tiene que ser un excelente técnico, ya que sin habilidad manual, experiencia y seguridad en el uso de herramientas, este conocimiento teórico o científico, nunca se convertiría en una obra terminada. Por otro lado, se tiene que ser artista, por que una cosa es que le pidan a una mesa para comer, y otra cosa es que entregue uno una verdadera obra de arte, diseñada no solo para ser funcional, sino para lograr un disfrute y un símbolo de orgullo en su propietario. El desarrollador como un artesano, se nutre entonces cotidianamente de las metáforas que mencionas.
Por ultimo, lo que considero mas importante de esta metáfora del artesano, es que nos permite sentir orgullo y satisfacción de lo que hacemos, en base a algo bastante mas valido y concreto. Conforme avanzamos y avanzamos hacia la maestría, nos retroalimentamos de la satisfacción de nuestros clientes y obtenemos mas satisfacción. Nos equivocaremos y cometeremos errores, pero un buen artesano entiende que si hay errores, no son culpa del cliente o de su "jefe", sino de nuestro mismo proceso de aprendizaje, es decir, tomamos responsabilidad de nuestra propia mejora, de lo que hacemos. Nos hacemos responsables de nuestro destino sin culpar a los demás. El tomar este control de nuestro propio trabajo, de nuestro propio crecimiento, es la puerta al nirvana.
Mis dos centavos sobre tus excelentes reflexiones,
Saludos,
Emilio
On 2/28/07, Vicente Raúl Plata Fonseca [XnT] <
xien...@gmail.com> wrote:
El Desarrollo de Software, en todas sus facetas, y con el afán de no
generar polémicas, generalmente es calificado como una "actividad".
Así, a secas.
El hecho es que existe un constante debate referente a, ¿bajo qué
categoría se podría calificar ésta "actividad"?
Entre las definiciones que personalmente encuentro más probables están
el arte, la ciencia y la técnica.
La ciencia generalmente utiliza un método fijo para comprobar una
serie de hechos que le permitan llegar a un resultado confiable, y
predecirlo antes de que éste suceda. Bajo ese entendido el Desarrollo
de Software bien podría ser una ciencia dado que en los "best case
scenarios" las cosas deben salir tal y como fueron planteadas en el
análisis (obviamente todos sabemos que tal resultado tiende a
imposible por múltiples factores, entre éllos casi siempre los errores
de capa 8).
La diferencia entre ciencia y técnica se dice que es: "la técnica se
basa más en el pragmatismo que en los hechos". Pero el desarrollo de
software si bien es en ocasiones pragmático, también depende en gran
medida de los hechos. De lo que se puede medir y comprobar. De lo que
se puede replicar.
En lo que refiere al arte, la cantidad de opciones para
personalización desde el código fuente hasta la propia aplicación
implementada nos permite calificar "nuestra actividad" como tal. Eso
aunado a la cantidad de gente que tira líneas y líneas de código por
el simple y vago placer de hacerlo.
Creo que ese sería un punto primordial antes de que cualquier
estudiante pensara siquiera en la posibilidad de dedicarse a ésto.
¿Qué es? ¿Ciencia, Técnica o Arte?
¿Qué opinan ustedes al respecto?
-Shakyamuni