Rodrigo Corral ha publicado en su blog una entrada sobre la idea del software "al modo industrial" que se explica desde su nombre: "La falacia de la industrialización del desarrollo de software ".
Más de una vez aquí se ha hablado de este tema: en realidad forma parte de la temática de éste blog, y no hace mucho se ha escrito sobre ésto. Como en muchos puntos lo veo de forma muy distinta, creo que debería dedicarle algunas líneas, a modo de extensión de lo que dejé en su entrada como comentario.
En primer lugar, creo que Rodrigo escribe pensando en la industria del software, en empresas específicas, y en políticas comerciales y de recursos humanos. Es probable que en este terreno tenga razones para sus afirmaciones sobre la necesidad de reconocer el valor de cada desarrollador.
Pero no comparto que se extienda el cuestionamiento al propósito de establecer criterios que normalicen el proceso de construcción. Si aceptamos que existe una ingeniería de software, se debe aceptar también que sus intenciones son reducir el riesgo y la incertidumbre en la construcción de software, establecer procedimientos, medir y proyectar, utilizar patrones repetibles.
Por supuesto, el desarrollador tiene importancia. Pero un equipo, y un plan de construcción, no pueden depender de las individualidades: desde hace mucho, reducir la indeterminación ha sido una preocupación generalizada, ante la evidencia de que sin criterios claros de manejo del proceso, un proyecto puede convertirse en interminable, o mucho peor, terminar dramáticamente sin lograr sus objetivos. La historia de la industria está plagada de estos casos. Además, el software debe ser mantenible: no basta crear un software por única vez, sino que debe sostenerse en el tiempo: si dependieramos de las individualidades, cada vez que se produjera una baja del equipo de trabajo, la situación sería calamitosa.
A diferencia de lo que Rodrigo mencionara, como bien se puede ver aquí, creo en la positividad de todas aquellas líneas de investigación que tienden a asegurar procesos más confiables, sea en la utilización de procesos repetibles de manejo del ambiente de construcción (Administración de cambios, seguimiento de defectos, manejo de configuración), como en las herramientas mismas de modelado y generación (generadores de código).
No creo que ninguno de esos elementos vayan en perjuicio del desarrollador, del recurso humano, sino que proponen una actividad más creativa, particularmente en el caso de las nuevas generaciones de 4GL, que permiten poner el acento en el modelado, en lugar del "picado de código".
Quizá la línea de investigación de Líneas de Producto Software sea el ejemplo más generalizador y demostrativo de qué es lo importante del "sofware como industria": SPL propone el planeamiento anticipado, la utilización de patrones, el reuso de partes, la existencia de un repositorio de componentes, la utilización de herramientas de generación de código.
Finalmente, quiero hacer notar que una vía artesana de trabajo, considerando el volúmen que adquiere la intervención de la informática en la economía y la sociedad, si fuera realmente el paradigma aplicado, haría que un alto porcentaje de desarrollos corrieran totalmente por detrás de su necesidad.
En fin, repitiendo lo que le escribía a Rodrigo, "no me gusta la idea de que la construcción de software es un arte, y el programador, un artista. Reconozco que en su construcción hay lugar para la creación y para la belleza (de un algoritmo o de una solución de arquitectura), y que forma parte de la motivación, pero también a esa disposición se la puede calificar con otros nombres, más cercanos a la ingeniería. No me opongo a su existencia, y es excelente trabajar con colegas que den soluciones brillantes; pero no creo que sea conveniente basar una estructura persistente en individualidades, porque dependeremos de ellos. El software debe ser mantenible, y debe tener tiempos de construcción estimables, o al menos planeables. La metáfora de la fábrica siempre la interpreté en ese sentido, y estoy seguro que todos aquellos que han rondado esta idea, lo han hecho en la misma dirección".
Estoy seguro sin embargo, de que la diferencia con sus afirmaciones se reducen a un matíz, que sin embargo quizá sea de importancia.
6 comentarios:
http://www.freeplay.com/Main/fpbook.htm
¿Has leido este libro?
¿Has preguntado a la gente de Google si sus brillantes ideas son producto de una actividad insdustrial o de una correcta administración y puesta en importancia del programador creativo por sobre cualquier cosa?
Hay diferencias significativas entre una silla fabricada a nivel industrial y algo con valor artístico.
No es ni una cosa ni la otra, son modelos de negocio distinto.
Eso sí, la diferencia de trabajo se nota y creo que si vamos a nivel de calidad es obvio que google gana.
¿Cual es la razón entonces para seguir negando la importancia del programador, de su capcidad para resolver problemas y su iluminaciones?.
Ninguna.
Martín,
Creo que hablamos de cosas distintas: no niego la creatividad de "los programadores" (ni la de los analistas, los arquitectos, los auditores...). El arte es otra cosa, pero, por ejemplo, la literatura, que parece interesarte, también requiere largas horas de trabajo disciplinado, utilizando las herramientas del idioma, la planificación de la materia que desarrollas, de documentación...
La construcción de software es un trabajo colaborativo ¿cuál es el problema con ésto?
La literatura no existiría sino fuera por el buen trabajo artístico que hay
detrás.
La música tampoco.
El software ¿Existiría? Si, pero no habría gente como Steve Jobs, o los amigos de Google, capaces de buscar, transgredir y saltar barreras.
Mientras más pensemos en esto como una máquina de dinero, menos vamos a innovar y crecer.
Por cierto,
Muy buen blog ;)
Creo que seguimos hablando de cosas distintas: ingeniería de software = dinero vs creatividad individual = arte no reflejan el problema. Picasso no tuvo inconveniente en ganar dinero, y era usual desde el Renacimiento buscarse un "sponsor"...
Te invito a que, cuando tengas tu consultora, propongas poner por delante la creatividad, el trabajo individual, y regalar el trabajo, cuando propongas tu primera oferta a un cliente.
Una vez más, la creatividad es importante, la iniciativa es importante, un trabajo con desafíos motiva, pero es un error proponer la construcción del software como un arte, y oponerse al establecimiento de métodos de construcción racionales, "al modo de la industria".
No sé si habrás leído aquí otras entradas relacionadas, pero creo que si las repasaras debieras aclararte un poco más sobre el sentido de lo que aquí se afirma. Si todavía pensaras en sentido opuesto, no veo mucho más para hacer.
Martín,
disculpas por la asincronía de mi última respuesta, que iba dirigida a tu segundo comentario. Un día después veo que había un comentario pendiente de moderar, que queda ahora intercalado. Así queda fuera de contexto.
Por lo demás, gracias por dar tu opinión, que como verás, es compartida por muchos.
Publicar un comentario