NicoPaez

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é.