Ya hemos hablado aquí en otras ocasiones sobre el problema de encontrar una forma metódica de crear programas grandes que no fallen. Es un problema no resuelto y hay gente que está dedicando sus vidas a encontrar nuevos paradigmas y cambiar la forma de programar que tenemos, pero hay otra tendencia que consiste en resignarse y aceptar que la programación nunca será como la arquitectura o la ingeniería de caminos.
Dos de los ingenieros de java defienden esta última posición en su libro The Pragmatic Programmer. Pero también circula por internet una interesante entrevista a los autores dividida dos partes: Parte1 y Parte2.
Básicamete su argumentación es que cuando construyes un edificio tendrá el mismo aspecto que en el mapa del arquitecto y éste se queda practicamente inmutable en el mismo sitio durante años y años, solo tenemos que hacer una mínima manutención. Mientras que en un jardín plantamos las semillas y no podemos saber realmente cual será el aspecto final, debemos ir retocando contínuamente cada planta para que el jardín no se convierta en un caos. La verdad es que la metáfora del jardín se parece mucho más a mi día a día con la programación que el caso del edificio.
There is a persistent notion in a lot of literature that software development should be like engineering. First, an architect draws up some great plans. Then you get a flood of warm bodies to come in and fill the chairs, bang out all the code, and you’re done. A lot of people still feel that way; I saw an interview in the last six months of a big outsourcing house in India where this was how they felt. They paint a picture of constructing software like buildings. The high talent architects do the design. The coders do the constructing. The tenants move in, and everyone lives happily ever after. We don’t think that’s very realistic. It doesn’t work that way with software.
We paint a different picture. Instead of that very neat and orderly procession, which doesn’t happen even in the real world with buildings, software is much more like gardening. You do plan. You plan that you’re going to make a plot this big. You’re going to prepare the soil. You bring in a landscape person who says to put the big plants in the back and short ones in the front. You’ve got a great plan, a whole design.
But when you plant the bulbs and the seeds, what happens? The garden doesn’t quite come up the way you drew the picture. This plant gets a lot bigger than you thought it would. You’ve got to prune it. You’ve got to split it. You’ve got to move it around the garden. This big plant in the back died. You’ve got to dig it up and throw it into the compost pile. These colors ended up not looking like they did on the package. They don’t look good next to each other. You’ve got to transplant this one over to the other side of the garden.
¿Pensáis que la programación será siempre una disciplina como la jardinería o llegaremos algún dia a crear una disciplina ingenieril formal para crear software?
Hace tiempo que sigo tu bitácora (compartimos las mismas pasiones) y por primera vez me he animado a escribir.
Curiosamente trabajo en el punto medio entre informática y arquitectura (3d de planos) y me da la impresión que es un poco difícil que se pueda sistematizar la programación tanto como lo hace arquitectura.
Esto es debido a que (acercando la arquitectura a la informática), la arquitectura podría dividirse en la interfase y la lógica interna… la lógica interna siempre es la misma (trasladar todas las fuerzas de la estructura hacia el suelo); lo único que varía es la interfase (cómo trasladar esas fuerzas, diseños de fachadas, modulaciones…).
Así, lo interno siempre es lo mismo y lo visible es lo que cambia.
Me da la impresión que la programación es mucho más amplia. Sólo se podría sistematizar tanto si se limitara a resolver siempre el mismo tipo de problemas (p.ejemplo bases de datos). Si a eso le añadimos lo «abstracto» de las soluciones programáticas, me da la impresión que podemos acercar la programación más al «arte» que a la ingeniería… eso sí, sin apartarnos de cierto grado de sistematización 🙂
Un saludo, Héctor.
Vaya vaya, como me alegra tenerte de lector y descubrir tu blog gracias a este comentario. Veo que compartes la visión de que la programación está a medio camino entre el arte y la ingeniería. Pero la verdad es que la Arquitectura es una disciplina que lleva muchos siglos evolucionando y se podría decir que ha madurado. Mientras que la programación (De alto nivel) cumple ahora mismo 50 años, es algo que acaba de nacer.
En ingeniería del software se intentan seguir los procesos ya puestos a prueba en arquitectura etc. tal y como tu comentas, la separación de la lógica interna y la interfaz se asemeja mucho a la arquitectura. Pero no parece que esa sea la solución definitiva a los males de la programación.
Yo también hace mucho que leo tu blog y esta es la primera vez que comento.
Personalmente, creo que es justamente esa diferencia la que hace a la programación una disciplina tan interesante. Se puede reconocer a un programador, no sólo su dedicación a su tarea, sino también por el espíritu que vuelca en ella… al igual que un jardinero con su jardín.
Pero, si nos ponemos a pensar, existen por todos lados libros, documentos, escritos en general que han estructurado las tareas de jardinería para que «cualquiera» pueda hacerlo. Es un intento de estructuración de algo casi azaroso. Con la programación es igual, en la actualidad casi cualqueira puede programar – el nivel es tema aparte – pero sólo aquellos realmente avocados a dicha tarea se podrían considerar «jardineros». Me niego a creer que es posible estructurar totalmente la programación, porque eso quiere decir que las personas somos programables. Al fin y al cabo, la programación se avoca a simular el pensamiento humano en situaciones más o menos definidas.
Es todo lo que puedo decir… y lo más claro que puedo decirlo.
Saludos desde Argentina
La programación también ha madurado. Dan fe de ello los lenguajes Orientados a Objetos, antes inexistentes.
Como decía el rastas de Sun en la entrevista que enlazaste en otro post … quizás la solución esté en que el soft reconozca patrones (como los naked objects) pero al nivel que lo imaginaba este tipet, roza la inteligencia artificial.
La informatica tiene grandes proyectos como el Kernel de Linux, o pensemos mejor en MySQL … si quisiera participar, tendría que aprender millones de cosas antes de escribir una línea de código, cosas relacionadas sobre cómo se ha programado y porqué, cómo se relacionan muchos los objetos que contiene, … y aprender y tener siempre eso en mente, roza el límite humano. Pasar esto a la AI es quizás la solución, y al mismo tiempo un nuevo problema.
Esta concepción es especialmente válida para el desarrollo web, de lo cual acabo de hablar en mi weblog.
Un saludo.
Hombre, me parece que más que comparar el desarrollo de software con la arquitectura o la jardineria, és mucho más ajustado a la realidad compararlo con la ingenieria industrial. Diseñamos objectos, por ejemplo un coche, y los vamos mejorando, sacando versiones mejoradas a lo largo del tiempo. Pero los cambios no los hacemos (totalmente) «a ojo», sino que estan (deberian) bien documentados y tener una razón de ser.
Llevo mucho tiempo dandole vueltas, por que creo que el termino «arquitectura de software» ha traido más cosas malas que buenas, y es que los «jefes» siguen pensando que un arquitecto es capaz de resolver todos los problemas que aparezcan a priori.
Gran comparación !!
En cierto modo ya se ha logrado,
Ya hay un programa que provee los codigos como o con solo un clic, pero mas bien creo que esto aplica a creacion de webs html mas que a programacion.
Perdon, me referia a o , que ponen las letras letras sombreadas o subrayadas. En ingles se les llama «markup tags»