Estoy con #61 claramente en esa línea de pensamiento de que programar es un arte. Cuando sueltas la famosa frase entre un grupo de desarrolladores se levantan ampollas enormes. Y, efectivamente, surgen los dos bandos.
No me apetece ahora soltar un tocho de los argumentos que tengo para estar a favor de que se acerca más al arte que a la ciencia. Por supuesto los pasionales/vocacionales no cuentan aquí. Me refiero a argumentos técnicos. Por ejemplo (al final voy a soltar un tocho...):
En 50 años de industria del software desde los 60, no es normal que el único estándar que se haya producido sea el UML. Y hablamos de una herramienta de lenguaje que sirve para comunicar conceptos de una forma común, nada más (que no es poco). Los patrones están muy bien y, de hecho, cuanto más tiempo llevas programando más te das cuenta de que llegas a la misma solución que tiene un patrón de diseño. Pero es sólo eso: un patrón, una forma genérica de abordar una solución a un problema. Pero al final hay que implementarlo.
En otras ingenierías (tengo un cuñado de Industriales especialista en estructuras) la creatividad está sujeta a muchos protocolos predeterminados donde no hay mucha libertad de movimiento. Y aun así la creatividad está ahí (arquitectura, por ejemplo).
Sin embargo, cuando programas tienes mil formas de abordar la solución de un problema desde el aspecto más arquitectónico hasta el algoritmo más concreto que hay dentro de un método. Puedes optar por trabajar de forma modular con funciones o con el paradigma orientado a objetos. Puedes trabajar con n-capas o meterlo todo en un mismo sitio. Es más, puedes usar decenas de lenguajes y decenas de herramientas. Y tener en cuenta la escalabilidad futura del software (un arquitecto de un edificio no tiene que tener en cuenta este hecho de una forma tan importante). Y, por lo general, muchos desarrollos no tienen un inicio y un final, sino que están en constante cambio con lo cual se cometen "errores" de planificación sí o sí porque los acuerdos iniciales varían y afectan a todo el sistema.
En definitiva, es tal la complejidad que hay que manejar que no hay proceso científico que resista esto como para estandarizar el proceso concreto de codificación. Insisto en lo mismo, la prueba de que es un arte es la cantidad de lenguajes, paradigmas, entornos, herramientas en los que se puede desarrollar. Si fuera tan fácil como comprar objetos y unirlos para fabricar software ya sería así y estaríamos todos en la calle o fabricando esas piezas (que las hay, pero para tareas muy concretas).
De todas formas, a veces pasamos por alto lo que significa ser un ingeniero. La wikipedia menciona lo siguiente:
Otra característica que define a la ingeniería es la aplicación de los conocimientos científicos a la invención o perfeccionamiento de nuevas técnicas. Esta aplicación se caracteriza por usar el ingenio principalmente de una manera más pragmática y ágil que el método científico, puesto que la ingeniería, como actividad, está limitada al tiempo y recursos dados por el entorno en que ella se desenvuelve.
Y creo que coincidiréis conmigo en que la resolución de un problema de la vida real y su implementación en miles de líneas de código tiene que ver mas con usar el ingenio que con cualquier otra práctica científica mas estandarizada.
En definitiva, el desarrollo de software es parecido a la arquitectura, tiene ciencia pero también tiene arte. Con la diferencia de que a los informáticos no nos aplauden cuando el resultado es bonito, eficiente, y sin errores (esto es una utopía xD), sino que siempre nos buscan las vueltas para criticar cualquier cosa que no se adapta a lo que el usuario espera.
Por eso este año no estoy aún en cuarto, porque no puedo matricularme. Pero voy haciendo prácticas y estudiando a ver si me saco todo 4º + optativas para el año.
