La falacia de la industrialización del desarrollo de software

Desde que escribí mi primera línea de código, hace ya unos cuantos años, siempre he percibido un ruido de fondo en la industria del software. Un ruido continuo y pertinaz. Un ruido que como un murmullo que vive entre las líneas de código dice: ‘el desarrollo de software es una actividad industrial’. Parece que hay mucha gente que está convencida de esto, que a mí me parece una falacia. Y que nadie piense que uso aquí la palabra falacia con un signifacado relajado, lo uso con todo su significado, según la RAE: ‘Engaño, fraude o mentira con que se intenta dañar a alguien’. Numerosísimas empresas trantan de hacernos creer que los desarrolladores somos meros peones intercambiables, piezas remplazables de una cadena de montaje, minusvalorando nuestra labor y dañando nuestras legítimas aspiraciones de reconocimiento profesional y económico. Y creo que se trata simplemente de no querer repartir el pastel, pero esta es otra historia. Creo que es hora de asumir que esta es una ingeniería en la que el valor está en sus profesionales más que en ningún otro aspecto y sobre todo una ingeniería que debe comenzar a trazar su propio camino.

Hay una serie de razones por las que a mí me parece evidente que si bien la ingeniería del software es sin duda una ingeniería (necesita del ingenio más que ninguna otra) es radicalmente diferente de la ingeniería industrial o la arquitectura u otras ingenierías digamos clásicas.

Es por eso que cualquier metáfora en la que se usen símiles con otras ingenierías es dañina en mi opinión y en la opinión de muchísimos otros miembros de la comunidad más relevantes que yo. Existe una gran controversia sobre este tema y como nó, me gustaría añadir mi granito de arena o más leña al fuego según como se mire.

Mi amigo Ibon Landa hablaba sobre esto a raíz de un anuncio de una empresa en dotNetMania y mucha gente me ha preguntado mi opinión sobre el tema, supongo que como consecuencia del revuelo que se armo cuando comenté otro anuncio anterior de la misma empresa, pues aquí va este post, en el que trato de explicar porque considero la ingeniería del software diferente a otras ingenierías y el desarrollo de software algo difícilmente industrializable.

Aunque considero que existen muchos motivos por los que el desarrollo de software es diferente voy a comentar los que me parecen mas relevantes:

En el desarrollo de software no es económico hacer todo el diseño y la especificación a priori

Diseño de Gaudi Cuando se trata de construir miles de vehículos tiene un gran sentido hacer una fortísima inversión en diseño y especificación a priori. Esta fortísima inversión se recupera diluyéndola en el coste de la gran cantidad de instancias de ese diseño que se van a implementar. En software esto no es cierto. De un diseño solo se hará una implementación (por mucho que se vendan millones de cds con ella) solo tendremos una instancia de un diseño determinado.

Otra diferencia importante es que el software no se puede construir principalmente uniendo elementos que ya existen. Durante un tiempo se pensó que si, incluso es algo que se persigue constantemente primero con el software construido mediante componentes y luego mediante el software construido orquestando servicios. Aunque ambos enfoques han ayudado a mejorar como se construye el software ninguno de los dos no libra de que todo proyecto tenga más líneas de código nuestras que ajenas. En la construcción de un coche, un barco, un avión o un edificio, lo que se reutiliza es mucho más significativo que lo que se construye de cero. Esto hace que, a igual magnitud del proyecto, el software sea mucho más difícil de especificar que un coche, un edificio o un barco: no podemos ahorrarnos diseño simplemente diciendo aquí se usa una capa de acceso a datos DIN 5722, sin embargo este enfoque es constante en la industria y la construcción.

Durante años se nos ha vendido que era posible la reutilización a gran escala, incluso se nos ha vendido herramientas 4GL que hacían de la especificación y el diseño a priori el enfoque primordial de desarrollo, pero sin duda los compiladores generalistas siguen siendo la principal herramienta de desarrollo. Si bien es cierto que cada vez se hace más uso de herramientas estilo DSL, estás no ha solucionado el problema de manera completa.

Con independencia del diseño que se haga a priori, cada línea de código que se escribe exige actividades de diseño. Sin embargo en otras ingenierías las actividades de construcción no implican tomar ninguna decisión sobre el diseño. El simple hecho de elegir el tipo de una variable numérica es una decisión de diseño. Solo los artistas toman tantas decisiones de diseño como los programadores cuando construyen algo, quizás por eso somos muchos los que pensamos que programar es un arte.

El entorno cambia constantemente

Cuando alguien se plantea construir un puente o un barco conoce de antemano el problema que va a solucionar. Este problema permanece constante en el tiempo. Esto no ocurre con el software. Los clientes a menudo necesitan saber que somos capaces de hacer antes de conocer realmente que es lo que quieren hacer. Nadie opina sobre el diseño de un puente porque reconstruir uno de sus tramos es sumamente costoso y rara vez hay valor alguno en esa reconstrucción. Sin embargo cuando un cliente, o un usuario ve un software, siempre se le ocurren maneras de cambiarlo para lograr obtener más valor. Evidentemente esto exige nuevas maneras de relacionarse con los clientes.

Además las herramientas , los lenguajes, las necesidades de calidad, los requisitos de rendimiento cambian, como mínimo, de proyecto a proyecto. En este entorno es poco interesante centrar tus esfuerzos en realizar un proceso repetible, es mucho más interesante buscar un proceso flexible. Esto no se da de manera tan clara en la industria o en el resto de ingenierías, el proceso básico de construcción de puentes y sus diseños no han cambiado desde la época de los romanos. Todos los puentes, por poner un ejemplo, tienen requisitos esenciales muy similares: unir dos puntos salvando un obstáculo. ¿Alguien podría hacer una descripción similar de los proyectos de software?.

Otra manifestación de esté cambio constante, de la relatividad de los datos que majamos, que nos aleja de otras ingenierías es la imposibilidad de utilizar métricas prescriptivas. Que el momento flector de una viga en voladizo supere cierto valor, sin duda dará como resultado que se rompa, pero, por poner un ejemplo, ¿cuál es el valor máximo de bugs abiertos que puede tener un proyecto antes de que la calidad percibida sea mala?. Es muy difícil gestionar los proyectos de software de manera puramente analítica pues la certidumbre es poca y la posibilidad de sesgar las métricas es amplia.

No existen actividades repetibles

Barco en construcción Cada línea de código, unidad cuántica de los proyectos de software, es única y solo es relevante en un contexto determinado. La industrialización se basa en la especialización y la repetibilidad. Todos los tornillos de rosca métrica son idénticos. Sin embargo no hay valor en construir dos piezas de software que sean idénticas.

Durante el desarrollo de un proyecto industrial o de construcción existen numerosísimas actividades que se repiten de manera idéntica. Incluso vasta con repetir elementos constructivos ensamblándolos para logra más funcionalidad. Basta añadir secciones para lograr un barco con más capacidad o basta con añadir más módulos para lograr una Terminal 4 de Barajas. Esto no ocurre en el software, cada módulo es radicalmente diferente del anterior al menos en algún aspecto. Por eso la especialización de los ‘operarios informáticos’ es, en cierto modo, contraproducente.

Además los desarrolladores se ven a si mismos más como artesanos que como operarios cuando describen su actividad profesional, por algo será.

La fuerza productiva no es fácilmente reemplazable

Y el desarrollo de software exige personal altamente capacitado. No existen dos desarrolladores con las mismas capacidades. Es relativamente fácil entrenar a un nuevo operario de planta es relativamente fácil sustituirlo por otro y la productividad no se verá mermada. Se puede tratar a los operarios de una planta como una máquina más (no digo que esto sea correcto, digo que es posible). Evidentemente las máquinas son fácilmente reemplazables al menos sobre el papel.

Todos los que hemos gestionado proyectos coincidimos que sea cual sea el proceso de desarrollo que seguimos el que un desarrollador cause baja siempre es un problema. Sabemos que nunca encontraremos otro con los mismos conocimiento y destrezas y con el conocimiento sobre el proyecto que el anterior atesoraba. Este es un tema que ya he tratado en anteriores ocasiones y por tanto no me extiendo más.

El software puede proporcionar valor incluso cuando no está completado

Puente en construcción Medio coche, medio barco, medio edificio o medio puente no sirven de nada. No son utilizables, no suponen un retorno de la inversión y además no se puede recibir feedback ninguno sobre el retorno de la inversión recibido frente al esperado y como mejorar este ratio.

La mitad de un proyecto de software, considerada como el momento en que la mitad de los requisitos están implementados, si se ha considerado el retorno de la inversión como principal parámetro a la hora de priorizarlos, aportará típicamente más de la mitad del retorno de la inversión esperado. Además es posible poner en producción la mitad de un software. No estará completo, cierto, pero no ayudará en múltiples aspectos. Dicho de otra manera Open Office es rival de Microsoft Office por un motivo claro, no necesitamos absolutamente toda la funcionalidad para que un software aporte valor. Además esta característica del software hace que sea mucho más fácil obtener feedback e incorporarlo al proyecto.

Existe un consenso claro entorno que a que una aproximación iterativa es la mejor manera de desarrollar proyectos de software. Sin embargo la aproximación en los proyectos industriales o de construcción rara vez es iterativa más haya de la fase de prototipado.

La motivación de los desarrolladores es lo que más influye en la productividad

Aunque existen muchos estudios y experiencias que hablan de que la implicación de los operarios de cadenas de montaje en el proceso productivo de principio a fin a logrado grandes mejoras de productividad, es cierto que el impacto de la motivación de los operarios industriales sobre el resultado final y la productividad es limitado.

Sin embargo, numerosísimos autores sobre gestión de proyectos informáticos han resaltado la motivación y la capacidad de trabajar como un equipo con el factor más determinante sobre los resultados de un proyecto. El primer autor en hablar y describir este fenómeno fue Boehm en 1981 y desde entonces son incontables los gestores de proyectos y las metodologías que lo han ignorado.

Dicho lo anterior, creo que es hora de olvidarse de tratar de llevar las técnicas de otras ingenierías y empezar a asumir que la nuestra es diferente y que debe encontrar su propio camino. Ya hay grandes nombres que está andando ese camino.

24 comentarios sobre “La falacia de la industrialización del desarrollo de software”

  1. Es interesante que en tu post dices lo absurdamente obvio pero supongo que hay gente que no piensa así.

    Pero eso Rodrigo, te enrollas mucho (y eso te lo digo de manera constructiva)

  2. Jajajajaj… sí que me enroyo un poco sí, pero es que es más barato que pagar a un psicoanalísta… es la manera que tengo de desfogarme, sobre todo los fines de semana que no voy al frontón a pegar cuatro pelotazos…

    Dicho esto, si eque es obvio en cierto sentido lo que digo, pero la prengunta entonces es ¿por qué siendo tan obvio se olvida tanto?…

    Saludos!!!

  3. «Dicho esto, si eque es obvio en cierto sentido lo que digo, pero la prengunta entonces es ¿por qué siendo tan obvio se olvida tanto?.»

    Igual porque hay gente que no piense por si mismo? No lo digo por ofender, pero es que de verdad a veces me sorprende.

  4. Muy de acuerdo con tu post.

    Cuando oigo a gente de mi empresa hablar de «software factories», «pool de programadores» y «outsourcing en India» me echo a temblar.

    El contrapunto son algunos «ingenieros de primera» que creen que ellos no deben programar, que me dan bastante risa. 😀

    También estoy de acuerdo en que te enrollas bastante 😛

  5. Pues no estoy muy seguro, creo que tienes razón en lo que dices, pero cuando entra en juego el usuario. Es él el que vuelve cambiante el entorno, al que le vale solo la mitad de lo realizado, etc… Pero, ¿y diseñando algoritmos de computación?, ¿creando sistemas de gestión de memoria?, ¿o sistemas distribuidos multicomputador-nodo?… ¿entonces hacerlos es un arte? 😐 Quizás tengamos sistemas formales para demostrar su funcionamiento.
    Creo que Dijkstra no estaría de acuerdo contigo, no? Yo no lo tengo muy claro :).
    Desde luego que pienso que lo que hago muchas no lo hago siguiendo sistemas formales (el 99.9% de las veces).

  6. Estoy contigo, ése es el problema, que la gente piensa que desarrollar software es
    como hacer (sin ser despectivo) Galletas María en serie….

    El otro día leí una frase que me jodió un montón, pero que en parte refleja la cruda realidad de nuestra profesión:

    «El software es como las catedrales; primero lo construimos, y luego rezamos».

    SaludoX.

  7. Ya me gustaría veros con un equipo de programadores que no saben si el código que están picando se ejecuta en el cliente o en el servidor y que solo están pensando en las próximas vacaciones para que me digáis donde están los «artistas de la programación».

  8. Estimado Yo:

    Pero que tendrán que ver churras y merinas…

    Si tienes un mal equipo tienes un equipo poco capacitado y eso solo se arregla con formación…

  9. Hola Rodrigo y demas contertulios.
    Yo quisiera expresar mi opinion al respecto. No tengo demasiado tiempo para explicarme, asi que explicare brevemente mi posicion.

    Por un lado Rodrigo tiene cierta razon, picar codigo requiere de un gran conocimiento del sistema, tanto del que se esta desarrollando como del sistema operativo destino. Programar no es solo poner lineas de codigo una encima de la otra como poner ladrillos. Porque si fuera asi, los programas, aunque mal programados cumplirian su funcion, pero me inclino a pensar que para programar «bien» se necesita cierto arte.
    Por otra parte, el comentario de «lunes, 07 de abril de 2008 15:20 by yo» tambien tiene razon, hay programadores que simplemente estan ahi por su trabajo, es decir, no son apasionados de la programacion, ni ven en ella un verdadero arte. A ellos les de igual como se programe una cosa, o si en 10 lineas se puede hacer la vilgueria del 15. Quizas esta gente si que pueden ser reemplazables, dado que quizas son los que generan este tipo de codigo: http://thedailywtf.com/Articles/The-RedirectException.aspx

    pero los que sentimos que el codigo vemos las cosas de otra manera.

  10. «Ya me gustaría veros con un equipo de programadores que no saben si el código que están picando se ejecuta en el cliente o en el servidor y que solo están pensando en las próximas vacaciones para que me digáis donde están los artistas de la programación».

    En la programación pasa como en todos los demás artes: no todos los pintores son artistas, pero ahí están Picaso, Goya, Rembrant, etc. ¿Cuantos aprendices hicieron falta para que salieran éstos?.

    Llevo más de 30 años en entornos de programación y la gente que he conocido ha sido de todo tipo, malos, buenos, regulares, con y sin responsabilidad. Ahora bien, cuando uno o mejor aún, un grupo ha sido bueno y ha trabajado en equipo, no ha habido límite a lo que han hecho o hubieran podido hacer, si les hubieran dejado.

    Y con Rodrigo Corral, casi siempre me pasa lo mismo: pone las palabras justas que expresan mis sentimientos sobre este tema.

  11. Andrechi, por eso hablo de una nueva relación con el cliente. Yo no quiero venderle nada al cliente. Yo quiero que el cliente me compre. Parece lo mismo pero no lo es.

    Cuando el cliente es el que te compra, tu puedes explicarle de manera abierta que tienes una determinada manera de trabajar y no necesitas vendele ninguna moto.

    Creo que se trata no de decirle al cliente que es lo que vas a hacer, sino que es lo que puedes tratar de hacer para que el consiga retorno de la inversión. Pretender que podemos decirle al cliente lo que vamos ha hacer por él exactamente es, a la vista de la historia de la gestión de proyectos de desarrollo, cuando menos pretencioso y cuando más una descarada mentira, al menos en mi opinión.

    Sobre lo que comentas de la capa de acceso a datos, veo muy a menudo aplicaciones que no se mueven simplemente porque alguien penso que el acceso a datos ‘es siempre lo mismo’. Tampoco comparto la idea de que buscar bugs es una tarea mecánica.

    Me ha gustado el símil del Canal de la Mancha y el rediseño.

    Un saludo!!!

  12. Antes que nada, perdón por el “yo”, he rellenado el campo de una manera un poco impulsiva y no creo que esté bien.

    Rodrigo, no me parece que esté mezclando “churras y merinas”, porque en este caso las churras y las merinas son informáticos que forman parte de esta industria (o no) del desarrollo de software. Eso si, como dice Juan, los que no sienten pasión por su trabajo existen, y creo que desgraciadamente son muchos. Insisto, no hablo de falta de formación, hablo de desinterés.

    Pero en lo que no estoy de acuerdo de base es en el intento de marcar unas diferencias que no son tan reales (todo no es blanco o negro). En todos los trabajos o especialidades, hasta poniendo ladrillos, hay personas apasionadas y que se consideran “artistas” de lo suyo. Eso lo vemos en científicos, arquitectos, carpinteros, mecánicos…

    Sobre algunos temas de tu post:

    “No existen actividades repetibles”. ¿Mantenimiento de datos? ¿Informes y reportes? Creo que sí hay muchas actividades repetibles…hasta automatizables.

    “El software puede proporcionar valor incluso cuando no está completado”. ¿Y una carretera tiene que estar terminada para aportar valor? ¿O un edificio?

    “La motivación de los desarrolladores es lo que más influye en la productividad”. Podemos quitar “de los desarrolladores” y poner casi cualquier cosa y esta oración sigue siendo cierta.

    ¿Somos en realidad tan diferentes?

  13. Rodrigo, creo que al final como he dicho en varias ocasiones las cosas no son tan extremas, no hace falta decir que se ve que no eres objetivo en tus opiniones, en cualquier y partiendo de la base que al ser tu blog te lo puedes permitir me gustaría sabes según tu teoria si piensas que todas las compañias deberían tener su propio sistema operativo, o su propia hoja de calculo. Esta claro que existe software industrial, llamase windows, office, etc. Existe grandes casos de sw generalista como el que hace google, por cierto una de mis fábricas de software preferida, donde los productos que fabrican son de una calidad asombrosa.
    Por otro lado, en el mundo del software todavía vivimos en …permitirme la comparación… en los trajes hechos por modistas a medida. Es como antiguamente, como no existia Zara o El corte inglés cada pueblo tenia su modista que se encargaba de hacer el traje a todos. Al final el traje era tan bueno o tan malo segun la pericia de la modista de turno. Hoy en día todos sabemos que se fabrican trajes estandar con diferentes medidas y la gente se intenta apañar con lo que encuentra, de todas frmas siguen existiendo modistas (un 1% de lo que había) que te harán un traje perfecto a tu medida pero a un precio excepcional, que hoy en día muy poco gente le compensa pagar, ya que la relación calidad precio de los grandes almacenas no está tan mal.

    En fin, que oomo vereis la tendencia es al Sw de grandes almacenes y los modistas como Rodrigo quedarán para la alta costura a unos precios acordes. Posiblemente todos ganaremos con eso.

    Con respecto a la India, un estudio reciente ha dicho que en España en los proximos años no habrá suficientes ingenieros para absorver la demanda del mercado, así que si no importamos personas o exportamos el trabajo, ya me direis que hacemos… os recuerdo que esto ya le paso a USA hace varios años.

  14. Hola Indio!!!
    Claro que no soy objetivo, nadie lo es. Por eso etiqueto este tipo de post con el tag opinión.

    Evidentemente no pienso que haya que tener un SO propio o una hoja de cálculo. Cuando escribo en este blog escribo sobre el 70% (siendo conservador) del desarrollo de software que se hace: aplicaciones de gestión guiadas por datos a medida. Lógicamente el desarrollo de software es algo tan amplio que hay cosas se salen de este ámbito, pero son las menos.

    Yo también pienso que no todo es blanco o negro tal y como dicen varios comentarios. Pero si quiero mover que la gente piense de otra manera o se plantee maneras diferentes de hacer las cosas no lo voy a lograr con medias tintas.

    Dices que no hay suficientes profesionales en España, y yo estoy deacuerdo, solo que no creo que la solución sea más profesionales sino mejores profesionales y sobre todo distintos planteamientos y distintos procesos de desarrollo de software. Así seguro que todos ganamos: generando más valor para nuestros clientes usando el ingenio y no la fuerza bruta.

    Externalizar a la India es un ejemplo de añadir fuerza pero no flexibilidad y capacidad.

    En EEUU lo hicieron y aprendieron dos cosas: uno que es más fácil en la teoria que en la práctica y dos, que cuando externalizas, pierdes la capacidad de aprender, son otros los que aprenden y lógicamente al final se quedan con tu pastel.

    Estamos en la era del conocimiento y el conocimiento se adquiere haciendo proyectos, equivocandose, adaptandose, si externalizas es otro el que logrará la ventaja evolutiva. Por definición solo se debe externalizar aquello que no añade valor o conocimiento a tu empresa pero en los proyecto de software hay muy pocas cosas sin valor. Hay un excelente artículo sobre este tema. merece la pena leerlo:

    The pitfalls of outsourcing programmers
    (http://forio.com/resources/the-pitfalls-of-outsourcing-programmers)

    Un saludo y gracias por los comentarios!!!

  15. Rodrigo, aquí estamos discutiendo unos pocos que tenemos interés en aprender, conocer las opiniones de otros y evolución profesionalmente. Pero somos la minoría. Y seguramente estemos bástate de acuerdo en cómo llevar un proyecto informático.
    En mi caso particular, estoy trabajando como Jefe de Proyecto para una gran constructora. Y tengo una analista, que es la típica persona que se quedo con la mentalidad del asp y el código espagueti. Cuando le hablo de programación en n-capas, mapeo de datos relacionales, pruebas unitarias, el tío me mira con mala cara como pensando que estoy como una cabra. Es una persona que se siente indignada porque no le dan toda la formación que le gustaría, pero no se ha metido en un foro en su vida. Tengo que estar mirando con lupa su trabajo. Así que mis mayores logros es pensar como decirle las cosas para que no se mosquee cuando le tiro para atrás su trabajo. Lo que estoy haciendo es una guía de estilo para torpes, en el que está todo detallado de donde hay que colocar cada cosa. Pero lo peor de todo es que le considero una persona responsable e inteligente.

  16. Como siempre, tremeeeeennnndo el post. Me gustaría comentar al respecto (igual me salgo del tiesto), y siempre bajo mi punto de vista, que una de las principales causas de esta mentalidad es la poca preparación de los responsables de IT (CIO, CTO, cherif de informática o como quieras), los cuales saben mucho de presupuesto, cumplimiento de objetivos económicos, planificación de reuniones, asistencia a reuniones, reuniones para planificar reuniones, jejejej, y todo eso, pero no tienen una preparación sobre gestión de departamentos de informática, proyectos, software especializado (ERP, WorkFlow, Ayuda Toma de Decisiones, CRM, etc.), etc. Una vez que llegan al puesto piensan, “coño, si hago un software que lo pueda usar durante 10 años y además me permita hacer programas como churos……, me podría tumbar en la poltrona y relajarme…..”. Esta mentalidad, no me preguntes como, la heredan sus inmediatos mandos, que pretenden fabricar ese software maravilloso que dándole a una palanca, comienza a fabricar aplicaciones como churros, olvidándose de conceptos como la creatividad, la innovación, la competencia, la optimización de procesos, etc, etc. Este tipo de mentalidad al final es heredada por la mayoría de personal que forma la “cadena de producción” creando “aplatanamiento”, conformidad, falta de interés, falta de preocupación, y sobre todo, fuga de personal con verdaderas inquietudes y capacidades.
    Creo que la creación de software (y por esto he discutido con muchas personas, todas ellas contrarias a mis “radicales” ideas) es algo que debe planificarse siempre en clave de innovación, utilizando la tecnología de ese momento o incluso la que está por venir (si se puede ir probando), ya que es lo único que puede diferenciarte en un mercado donde las innovaciones se reciben por canales cuya principal característica es “el tiempo real”, como internet y donde el tiempo de reacción es muy limitado, ya que intentar amortizar u obtener un “roi” desproporcionado por “una librería de acceso a datos”, puede salirte muyyyyyyyy caro. Pero claro, para eso hay que tener …, ganas, formación y personal realmente implicado con esta apasionante profesión.

  17. Muy interesante discusion…
    Tomandolo en el sentido de «fabrica» de software, estoy totalmente de acuerdo de que la «industrializacion» del software es una falacia. Siempre se manejan metaforas sobre la creacion de software, a veces ayudan a visualizar el proceso, pero pensarlo como «fabrica» creo que limita mas de lo que ayuda. Si piensas hacer software como quien hace chorizos, lo que obtendras son chorizos :).
    El desarrollo de software es complejo, yo siempre vuelvo a «No silver bullet»: la esencia del desarrollo de software hace que no exista ninguna «solucion magica» que incremente la productividad en un orden de magnitud (que vendria a ser la promesa de la «industrializacion»).
    El problema de crear software no es producir componentes en serie de acuerdo a una especificacion, sino es lograr esa especificacion… el codigo del programa es la especificacion.
    La metafora de la construccion de puentes se utiliza mucho (y tambien tiene sus limitaciones!), pero nadie diseña un puente en un dia, lleva su trabajo y cada puente es distinto. Y eso que el problema es unir el punto A con el punto B salvando un obstaculo!! (me encanto esa definicion).
    Por otro lado, yo no considero la programacion como arte (no conozco nadie que escriba codigo porque «queda bonito») sino una herramienta para resolver problemas. Si creo tambien que la metafora de «artesano» tambien es limitante, y que aplicando los metodos y herramientas adecuadas al problema se pueden alcanzar los reslutados esperados.
    Eso si, a no olvidarse de la herramienta fundamental para desarrollar software: el cerebro!

  18. Rodrigo,
    Difiero aunque no estoy seguro con qué alcance. quizá no tanto con las razones que te llevan a encarar el tema, si estas tienen que ver con un estilo de empresa que pretenda establecer una «cadena de producción», y venda horas hombre; un estilo de «fábrica de software» que tiene seguramente bastante fuerza en los países receptores de outsourcing. Quizá en este caso pueda aplicarse tu calificación de falacia («Numerosísimas empresas trantan de hacernos creer que los desarrolladores somos meros peones intercambiables, piezas remplazables de una cadena de montaje, minusvalorando nuestra labor y dañando nuestras legítimas aspiraciones de reconocimiento profesional y económico. Y creo que se trata simplemente de no querer repartir el pastel»).
    Pero a mí, y creo que a muchos otros, la idea de «fábrica de software» me atrae, en la medida que apunta a una manera más rigurosa de construír software. Y te aseguro que no lo digo como «engaño, fraude o mentira, con la intención de dañar a alguien».
    Pero es que también difiero en un punto que sostiene lo que afirmas: 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.

  19. Ante todo un saludo desde Panamá a todos, ya que me da la impresión que la mayoría son coterráneos. Estoy muy de acuerdo con casi todo lo que ha planteado Rodrigo, la verdad que considero su punto de vista sobre muchos aspectos, muy certeros. Pero quiero agregar mi opinión sobre algunos aspectos. El grado de incertidumbre en el desarrollo de software actual radica simplemente que está construido sobre un principio dialéctico (0 y 1, sistema binario) La compleja danza que estos dos señores hacen…genera un mundo maravilloso que todos conocemos…y es un reflejo de nuestra mente dual, para entender contraponemos en conceptos opuestos y así nos acercamos a una opinión más satisfactoria. ¿Qué si es un arte? Estoy completamente de acuerdo!!! Ser un excelente constructor de software requiere tener desarrollado el mundo logico-matemático muy bien, esto no implica que seas un experto en el desarrollo de ecuaciones diferenciales, o en topología o en teoría de grupos, etc. Ya que el pensamiento lógico-matemático se manifiesta de muchas maneras. Pero esto lo digo por una razón, un código sí puede ser bello y elegante como los son las ecuaciones matemáticas y mientras más elegante sea una expresión matemática más seguro podemos estar que representa la realidad universal, lo dijo Einstein y muchos matemáticos estamos de acuerdo, entre ellos el gran Platón cuando definió la divina proporcion en términos de la armonía estética. Esto me permite concluir que un constructor de software, como eran los antiguos constructores de las catedrales son artistas, se necesita ser sensible a la elegancia de la solución propuesta a un problema determinado, aunque hay muchas soluciones como bien ha dicho Rodrigo, hay unas que son mejor que otras y elegirla requiere de gusto por la estética en los algoritmos. Al desarrollar un proyecto hoy día, ya no usas un sólo lenguaje, no usas un único framework, más la base de datos, más AJAX, más SOAP, XML, etc, etc, etc. Simplemente organizarlo todo siempre da una solución única para cada proyecto en la mayoría de los casos, los tiempos son altos, los costos son altísimos para nosotros los constructores ya que la creatividad, la lógica, la organización, la percepción, la coordinación, todo lo que hay que tomar en cuenta resulta a veces espeluznante para el común de los mortales, sencillamente me hago eco de una frase que vi en una película en estos días, si supieran lo que tengo en la cabeza les explotaría!!!

  20. Hola, me queda claro que nadie tiene la verdad absoluta en este tema, sin embargo, se han planteado argumentos de tal manera que te hacen pensar de manera diferente, y creo que allí esta el valor de este blog.
    He trabajado con todo tipo de personas, desde los motivados en hacer su mejor trabajo y estudian y analizan los retos que se le presentan, hasta los que programan solo por salir del paso. Con proyectos de un solo hombre hasta proyectos con equipos completos de desarrollo, pruebas, arquitectos etc.
    De igual manera con proyectos de implementacion de software supuestamente «maduros y estables» hasta proyectos que han sido vagamente definidos.
    Por todo lo anterior, considero que estamos en la era de artesanal del software y nos falta algunas generaciones para llegar a la industrialización, puesto que aun no se ha podido llegar a tener la posibilidad de comprar «ladrillos de software» o «piezas de software» que sean de armar y sirvan para diferentes usos, que es tan solo uno de los componentes de una industrialización en el desarrollo de software.
    De igual manera el diseño de software todavia depende de hacer ladrillos y no de armar estructuras (piezas de carros, puentes, etc.) Y todo esto afecta tiempos, presupuestos y que adicionalmente todavia hablamos de artistas para hacer ladrillos.
    Por lo que ha este punto todavía, de manera general en un alto porcentaje no se tienen la madurez (la industria del software) para pensar en hacer unas «galletas maria» que se usen por todos y así poder llegar a la etapa de replicación sin mayor esfuerzo.
    Esto se va ha dar cuando los clientes (usuarios, empresas, etc.) puedan entender y limitar sus expectativas a productos y cuando las herramientas permitan pegar ladrillos según la estructura que necesitemos.

    Recuerden que en la industria de la construcción ningun ingeniero de puentes u operario se pone a ver como mejorar un ladrillo, una viga o un tornillo (cosa que si hacemos en software), mas bien se basan en escoger el que mas se acomode a su presupuesto y sus requisitos.

    Saludos

Responder a rcorral Cancelar respuesta

Tu dirección de correo electrónico no será publicada. Los campos obligatorios están marcados con *