Por estos días me encuentro leyendo el libro «Software Craftsmanship: The New Imperative» de Pete McBreen. Es un libro que tiene casi 20 años y que a mi entender no ha tenido gran difusión. De hecho yo lo encontré por casualidad. No es mi idea en este artículo resumir el libro sino simplemente detenerme en esta idea de «Good Enough Software Engineering» que es una de las ideas que menciona el autor en la primera parte del libro y que recientemente me resonó mucho a partir de un intercambio de mensajes con mi colega Carlos Peix.
McBreen pone en tela de juicio el «enfoque formal» propuesto por la ingeniería para el desarrollo de software. Argumenta que la ingeniería de software resulta sin duda un enfoque apropiado para ciertos tipos de sistemas que implican el desarrollo conjunto de hardware + software y que ponen en juego la vida humana. En este sentido menciona proyectos militares y aeroespaciales. Sin embargo cree que el enfoque de ingeniería de software no es apropiado para el desarrollo de lo que llama «software comercial», cuyo desarrollo no requiere del desarrollo de un hardware particular y que no pone en juego vidas humanas, pero que tiene ciertas restricciones de mercado. Dicho de otra forma: los trade-offs que pueden hacerse en cada uno de estos dos tipos de proyectos son distintos y eso da lugar a distintos enfoques. Según MeBreen el desarrollo de software comercial va mejor con un enfoque de «good enough software» que con un enfoque de «Ingeniería».
Creo que somos varios a los que nos resuenan estos cuestionamientos que hace McBreen. De hecho recuerdo un artículo de David Parnas publicado en IEEE Software: Software Engineering – Missing in Action: A Personal Perspective, en el cual también se cuestiona el enfoque de ingeniería para el desarrollo de software. McBreen insiste en que para muchos contextos (la mayoría según él) hay enfoques más apropiados que el de ingeniería de software. Más aún, cree que hay varios enfoque posibles pero se inclina a hacia un enfoque de «artesanía».
Estas reflexiones plantean interesantes dilemas para practicantes y académicos. Como practicantes debemos entonces ante cada nuevo proyecto decidir que enfoque utilizar. Como académicos aparecen algunos cuestionamientos profundos:
- ¿está bien que las carreras de informática sean ingenierías o deberían ser licenciaturas y de esa forma despegarse de la «carga conceptual/cultural» que la ingeniería impone?
- ¿es posible/conveniente cubrir dentro de una misma carrera enfoques de ingeniería y de «no ingeniería»?
- ¿deberíamos tener carreras más específicas en línea con distintos enfoque de desarrollo?
Mi sensación es que en la actualidad muchas carreras, independientemente de su nombre, proponen un enfoque ingenieril pero luego una importante porción de sus egresados terminan trabajando en proyectos que podrían resultar más afines a un enfoque de artesanía.
Un detalle importante aquí es que un enfoque de ingeniería no es más completo ni abarcativo que un enfoque de «no-ingeniería» sino que es divergente. Esta divergencia que yo veo no es necesariamente conceptual sino «operativa» en un punto: las carreras tienen un límite de tiempo, enseñar un enfoque de ingeniería trae de entrada toda una base de conocmiento que reduce el espacio/tiempo para estudiar otras cuestiones. Esto queda muy en evidencia cuando en la actualidad vemos «ingenieros de software» que no buenos desarrolladores. Mi percepción es que muchas de las carreras actuales de «Ingeniería» (más allá de que sean formalmente ingenierías o licenciaturas) no forman buenos desarrolladores.
En fin, creo que este tema da para mucho, continuaré.
Blog de NicoPaez 
interesante, la verdad me da curiosidad el libro voy a verlo. Me parece un debate copado la ingenieria y la licenciatura sobre todo con las curriculas de cada casa de estudio. Justamente hay algunas universidades que cumplen https://www.asiin.de/en/programme-accreditation/quality-seals.html. Igualmente como comentas este tema da para mucho.
Gracias Rodo. Hay varias «certificaciones/acreditaciones» sobre carreras pero en general (y creo que las que mencionas no son la excepción) tienen un sesgo muy académico y/o ingenieríl, lejos da la idea de artesanía.
Muy interesante, y creo que existe un area de «artesanía en el software», mas que artesanía diría artística, el problema en nuestra carrera es cuando esa artesanía o artística oculta falencias de calidad en nuestro software, ahi es donde resurge de forma muy importante la estructura ingenieril.
Esta bueno el concepto de “Good Enough Software Engineering” pero quien define que significa «Good Enough»?
Gracias Diego por el aporte. Respecto a «¿quien define que significa Good Enough? para mi la respuesta es simple: el mercado.
(antetodo gracias por escribir el texto que inspiró a este comentario)
A veces la óptica con que se mira lo que las personas hacen, define una escala de valores que no aplica a lo que TODAS esas personas hacen.
El hacer ingeniería está bueno para dimensionar el esfuerzo de quien construye un instrumento, una maquina; pero resulta que no todas las personas (que hacen software en este caso) consideran que el resultado de hacer software sea «un programa». Algunos (no todos) consideran que cuando programan están haciendo un sistema; que incluso cambia mientras uno «lo escribe».
Otros piensan en términos de redacción (escritura de fuente), de construcción de una cosa (diseño de una arquitectura)… para estos el fruto de su esfuerzo es claro y mesurable.
Es muy frecuente hoy, en un mundo altamente comunicado y sin distancias, que las personas realizan una actividad social; y allí es donde ocurre «el arte» (el arte es lo que pasa en sociedad, el arte NO esta en la obra, ni en el autor; sino que ocurre cuando algo se presenta y a otros interesa… allí es dónde ocurre el evento artístico).
En el caso de sistemas virtuales (por ejemplo, con el uso de Smalltalk), la persona «está» en el sistema, allí se encuentra, rodeado de si mismo (el espejo que antes era la pantalla se ha desecho en minusculos pedazos de su historia) y punga por la sustentabilidad de ese sistema virtual.
Ese es el marco dónde hoy ocurre la actividad informática (Smalltalk es una actividad, no un contenido).
El producto de esta actividad NO esta en la computadora, sino en la mente de la persona que hace Smalltalk (a veces en grupos pequeños).
Lo que se produce no es un programa, ni un sistema; la actividad produce personalidades (personas que se desarrollan en forma autodidáctica y en pequeños grupos) que utilizan un soporte virtual para el abordaje de la problemática de sustentabilidad de sistemas virtuales abiertos.
Estos últimos párrafos distan mucho de la definición original y clásica de Smalltalk; siendo mas actual, creo, que las visiones del desarrollo de software de hace 30 y 20 años; dónde muchos nos planteábamos el dilema productivo/constructivo frente al artístico… mucho cambio este mundo y poco avance hay en la dirección del desarrollo de sistemas abiertos de objetos virtuales (Smalltalk).
Creo que hoy es un momento dónde uno puede ser protagonista de abordajes innovadores en tecnología, pero es importante dejar atrás lo que ha pasado (visiones de un mundo que ya no es) y abordar en sociedad las piezas que permiten hacer realidad un avance en informática; estas piezas son, hoy sistemas Smalltalk, no libros con letras que no se mueven 🙂
Gracias Alejandro por el aporte. Es interesante lo que mencionas de Smalltalk pero lamentablemente es una tecnología que nunca logró una adopción masiva. A pesar de ser anterior a Java, Python, Ruby, JavaScript etc, sigue siendo hoy en día una tecnología de nicho. Ojo, digo esto habiendo utilizando Smalltalk, habiendo trabajado con el equipo core de Pharo y habiendo enseñado Smalltalk por años. De todas formas creo que la cuestión ingeniería/artesanía excede por mucho la herramienta de programación, más aún creo que la herramienta, a partir de cierto nivel de abstracción, no es más que un accidente.
Nico, creo que cuando hablas, al menos en referencia al libro que mencionas sobre “el” método de la ingería de software, hay una confusión en pensar que esa manera particular de resolver es “toda” la ingeniería. En mi punto de vista hay un conjunto de prácticas que son apropiadas cuando se tienen los requerimientos relativamente firmes y conocidos. Y qué hay otros métodos apropiados cuando los requerimientos son más volátiles (cambiantes o no conocidos plenamente). Lamentablemente la idea del “craftsmanship” es leído como que no es necesario “saber” para hacer software útil. Las empresas pueden aplicar los métodos que consideren, pero el si creen que el conocimiento es caro o inaplicable, que prueben con el caos.
Hola Charly, me suena raro lo que decís de «la idea del craftsmanship es leído como que no es necesario saber», yo creo que es completamente lo contrarío. Hay que saber y ese saber no es posible obtenerlo con la educación formal. Hay parte de ese saber que viene exclusivamente de la práctica y la experiencia y es muy difícil adquirirlo (y transmitirlo) en la educación formal.