¿El desarrollo software es una ingeniería o una artesanía?


¿Son los ingenieros software realmente ingenieros o son algo más cercano a un artesano? Por artesano nos vienen a la cabeza aquellos que ejercitan un arte, quienes hacen por su cuenta “objetos de uso doméstico imprimiéndoles un sello personal” (RAE). El ingeniero, según la IEEE, es aquel que aplica un enfoque sistemático, disciplinado, cuantitativo a la hora de desarrollar software.
Este es uno de los debates más antiguos entre los profesionales del desarrollo software. ¿Es la ingeniería del software una ingeniería cómo las demás? ¿No lo es por su poca madurez pero llegará a serlo o nunca lo será por trabajar con un producto diferente? Podemos encontrar tantos argumentos a favor como en contra. Tantas críticas a hacia aquellos que ven el desarrollo como una ingeniería, como críticas a aquellos que no quieren trabajar de manera ingenieril.
Decenas de estándares y publicaciones que recomiendan y cuentan cómo usar procesos repetibles, sistematizados, ingenieriles, industriales, etc. Y también destacadas publicaciones, importantes libros, abogan por lo contrario.

El movimiento a favor de la artesanía software arranca en 1999, con la publicación del “The Pragmatic Programmer” de Hunt y Thomas, y toma fuerza en 2001 con la publicación del “Software Craftsmanship” de McBreen, quien acuñó el término. Posteriormente, Richard Sennet, quien curiosamente es filósofo, trataba al software como una “nueva artesanía” en “The Craftsman” (2008). Y ya en 2009 incluso se crea el manifiesto sobre el “software craftsmanship”.
Quienes defienden que construir software es una artesanía basan principalmente el desarrollo en las personas y sus capacidades, por encima de procesos repetibles y sistemáticos. Creen, por ejemplo, que la mejor, y a veces única, manera de aprender es trabajar con otras personas más expertas, con un maestro.
Aunque muchas veces, en las conversaciones de la calle, hay quien considera la artesanía como única alternativa válida al desarrollo, los padres del movimiento dejaron abierta la puerta a la convivencia de ambos enfoques, el ingenieril y el artesanal. Así, Pete McBreen en su libro “Software Craftsmanship” pone el ejemplo de la construcción ingenieril del software del “space shuttle”, que con 420000 líneas de código sólo tenía un bug.
Claro que, según comenta McBreen, en este tipo de sistemas críticos una estructura rígida puede tener sentido, y una visión artesana del desarrollo no aplica, pero en estos sistemas los costes son desorbitados. Y en la mayoría de los desarrollos software esta aproximación no tiene sentido. La gran mayoría de desarrollo trabajaría mejor con un enfoque artesano, basado en el conocimiento de las personas, con equipos pequeños, por encima de sofisticados procesos.
¿Y tú qué opinas? Será un placer leerlo…

Javier Garzás

11 comentarios en “¿El desarrollo software es una ingeniería o una artesanía?”

  1. Pingback: Bitacoras.com

  2. creo que si se debería tratar como una ingenieria puesto que con el software craftsmanship el codigo se refactoriza segun unos patrones conocidos y no a criterio de cada uno, y se puede cuantificar (complejidad ciclica, cohesion, dependencias..)

  3. Tema interesante para un martes por la mañana… 🙂
    Para centrar las cosas, vamos a hablar de cómo es el proceso en otras industrias.
    Primero la fabricación: vamos a considerla como conversión de planos en producto. Cuando hablamos de coches, esto es un reto, hay todo un proceso de ingeniería para construir la fábrica para ensamblar un nuevo modelo (ya diseñado o en proceso). En software, sin las mismas ataduras del mundo físico, esto es automático desde hace como 5 décadas: ‘make’. Listo. Conversión automática de planos a producto final. En el caso de los coches tienen que ‘inventar el compilador’ en cada producto (a ver cuando se ponen las pilas y estandarizan) 😀
    Por tanto, centramos la discusión de artesanía vs ingeniería en la parte de diseño únicamente, ya que la de construcción no es comparable por ser automática en el software (ojo, no hablo de ‘sw construction’ como lo entiende el SWEBOK o McConnell, hablo coloquialmente de conversión de planos en producto).
    Y aquí es donde entra la definición de qué es ingeniería. Haciendo una adaptación de la definición: «es la ciencia, profesión y capacidades para aplicar conocimientos científicos, económicos y prácticos y diseñar y construir nuevos productos y estructuras».
    Ingeniería viene de ‘ingenio’ y no recuerdo ahora dónde leí (creo que fue en The Existencial Pleasures of Engineering, pero no estoy seguro) que parte de la ‘magia’ se perdió a mitad del siglo pasado cuando la invasión de las matemáticas en la física y en la ingeniería creó la moda (que todavía persiste) de que si algo no se expresaba con una fórmula (a ser posible incomprensible)… no era ingeniería. Ese estigma, supongo, es el que hace dudar si el desarrollo de software es ingeniería o no.
    Lo de ‘repetible’ (que no veo en la definición, por cierto) entiendo que es un rollo muy aplicable a la construcción y que les mola mucho a todos los amigos del CMMi y similares.
    Pero, ¿es repetible el proceso de diseño de un nuevo coche? Entiendo que sí, pero no más de lo que lo es un nuevo producto software. Hay incertidumbre, prototipado, se desechan ideas, se prueban otras nuevas, se chequea con los clientes, se hacen pruebas en el túnel de viento para ver si la cosa funciona o no, simulaciones… Vamos, que como todo proceso que de verdad requiere ingenio, no es sota, caballo y rey.
    La diferencia, en mi opinión, viene en la forma de afrontar el proceso: un ingeniero conoce la ciencia que hay detrás e intenta desterrar de su cabeza el desconocimiento. Un ingeniero mide, razona, compara y decide. Por supuesto se basa en su experiencia para la toma de decisiones, pero este es otro tema (recomiendo Pragmatic Thinking and Learning).
    Por poner un ejemplo muy sencillo y un poco exagerado: un ‘esto va lento porque algo del sistema le hace ir mal’ es, además de poco profesional, muy poco ingenieril. Sin embargo un ‘he medido el proceso y consume un 25% de CPU durante 20 segundos y tiene un acceso a disco de escritura de X y eso causa que se ralentice blah,blah, blah’ es otro cantar. Es curioso porque casi todos los novatos te dicen cosas como ‘escribo este código porque es más rápido’ en lugar de ‘este código reduce la operación de 250ms a 25ms en una máquina con estas características, y dado que es una operación que el servidor tiene que procesar constantemente, es interesante optimizarla’.
    En definitiva, el desarrollo de software es (citando a Charles Simonyi en ‘Software Superheroes’, primer turista espacial e ingeniero jefe de MS Office durante dos décadas) el mayor reto intelectual para el ser humano de finales del XX y principios del XXI. Como tal, requiere de todo su ingenio. La aplicación estructurada del ingenio y de conocimientos científicos, económicos, prácticos, a ser posible aplicando el método científico, es ingeniería.
    Es más, muchos de los que se consideran ‘artesanos’ lo que intentan es huir de la rigidez de prácticas pseudo-ingenieriles (intentando comparar la ing. de sw. con la construcción, la peor de las comparaciones del mundo), que piensan que la rigidez, la repetitivad (que no consiguen muchas veces) y los ‘recursos reemplazables’ son el sumun, y realmente (los ‘artesanos’ digo) aplican muchas más prácticas ingenieriles que los segundos.
    Saludos

    1. ¡Amigo! que tarde he llegado. Ingeniería nunca ha venido de la palabra Ingenio. La palabra Ingeniería es una españolización desde el inglés de la palabra Engineer, la cual viene de Engine, que literalmente se traduce como Motor, o maquina. Nada que ver con ingenio.

      1. Te cuelas, bastante. Engine viene de Ingenio.
        1250-1300; Middle English engin < Anglo-French, Old French < Latin ingenium nature, innate quality, especially mental power, hence a clever invention, equivalent to in- in-2+ -genium, equivalent to gen- begetting (see kin ) + -ium -ium

  4. Esa es una de las preguntas que siempre me han acompañado y he querido saber la respuesta exacta.
    Partiendo de la premisa de que ingeniero es la persona que hace ingeniería; teniendo claro los conceptos de ingeniería, conociendo que el tamaño de una aplicacion depende del tipo de problema a resolver y que en en el mundo real en todos los productos de software no se aplica alguna metodología de desarrollo.
    La respuesta no la da la academia, puede estar en las corporaciones, que requieren las empresas y que se les ofrece?

  5. En verdad que el debate se centra en una u otro. Pero considero que encuadrar un todo en un lado u otro no del todo cierto.
    Ahora, si es cierto que se puede desarrollar SW netamente siguiendo un proceso de ingeniería, dependiendo del tipo de SW por ello es que tenemos patrones de diseño para estos casos.
    Tambien es cierto que hay sw que requiere le llamo yo «Quemar Neuronas» es decir ingenio, para encontrar la mejor solución, eso es un razonamiento humano.
    Con estos antecedentes pregunto: Si la ciencia médica es ciencia, y todos los médicos practican o siguen esa ciencia, porqué para una cirugía particular va donde un médico de gran prestigio?
    Me respondo, porque se quiere ir a lo seguro, ese otro médico además de seguir la ciencia tambien tiene un talento artesanal de tener menos fallos.
    Igual es con el sw, existen muchos ingenieros, pero sus destrezas, la forma como afrontan y resulven problemas siempre será importante para el sw a desarrollar.
    Tambien existen niveles en el desarrollo, así mediante estandares se puede mantener el control del desarrollo de sw dando las guias a los programadores y un ingeniero encargado de unir las partes poniendo ciencia e ingenio o artesanía.
    Saludos, es un gusto compartir y aprender de ustedes.

  6. Pingback: ¿El desarrollo software es una ingeniería o una artesanía? | Orgulloso de ser Ingeniero en Informática | Scoop.it

  7. Completisimo comentario, a nivel de post!
    De entre todo lo expuesto, resaltar que aun seguimos dandole vueltas a lo que mencionas del diseño, si si, si no, si detallado, si automatico, etc., Y en esas llevamos 60 años.
    Estaba escribiendo algo sobre ello..
    Gracias por la exposición

  8. Buenas, … Interesantes reflexiones.
    ¿Leonardo DaVinci era un artesano? ¿un ingeniero? .. Un genio! .. Bueno, de eso no hay duda.
    Me gusta lo que representa la ingeniería como aplicación sistemática de un conocimiento (soluciones) probadas. Lo veo necesario para centrar el esfuerzo intelectual en los retos y no desgastarnos en las tareas «de mantenimiento». Vamos, lo de no inventar la rueda en cada proyecto. No parece que sea pedir demasiado, ¿no?. Sin embargo …
    Me gusta la artesanía por lo que representa de estar cercano al producto final, moldearlo o palpar tu influencia sobre el mismo. Me gusta por lo que supone de adaptar y adaptarte a los medios disponibles.
    Me cuesta ver el negocio sin volumen, y el volumen sin ingeniería. Me cuesta ver la exquisitez o la diferenciación sin la cercanía, y la cercanía sin la artesanía.
    En el #AOS2012 estuvimos a vueltas con ello, convocados por un artesano «en apuros» («si me apoyo en mejores herramientas, ¿en qué momento creéis que dejo de ser artesano?»). Sensaciones encontradas.
    Bien, esta es mi reflexión. Todo aclarado ;).
    Un último punto. Hay gente que no concibe su trabajo fuera de una cadena de montaje y gente que no lo concibe sin la libertad del artesano. En el desarrollo SW también tenemos de todo. Si al menos acertamos en poner a cada uno en su hábitat adecuado, ya tenemos algo bueno ganado.
    Lo inmaterial de nuestra «materia prima» nos ha permitido avanzar a hipervelocidad en relación a otras disciplinas técnicas. El futuro pinta interesante. Podemos avanzar en ambas direcciones, aunque un colapso mundial en el 2020 por un defecto mal encarado seguro que no resulta nada divertido ….
    Saludos
    MAN

Deja un comentario

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

Ir arriba