Del conocimiento esencial y del accidental

De todos los monstruos, quizás uno de los peores sean los hombres-lobo, porque son personas aparentemente normales que, de repente, se transforman en un ser horrible.

Aunque frente a ellos no hay porque perder la esperanza, ya que usando balas de plata (silver bullet) podemos acabar con ellos. Muchos proyectos software se comportan de igual manera, de repente se transforman en seres horribles (tiempos y costes se disparan, incidencias, incluir una nueva y simple funcionalidad conlleva disparatados esfuerzos, etc.), e igualmente, muchas veces, nos ofrecen, o buscamos, sugerentes balas de plata que rápido, con apenas esfuerzo, nos solucionen el problema (bastaría pasar por algunos foros y conferencias para ver muchas “balas de plata”), tecnologías que de manera casi inmediata prometen acabar con el monstruo en el que en ocasiones se convierte un proyecto software.

Pero, que sepamos, hasta la fecha apenas se han descubierto unas pocas balas de plata, y ya hace tiempo de ello.

Las anteriores ideas son una paráfrasis personal del influyente artículo que Brooks escribió en el 87 (No Silver Bullet. Essence and Accidents of Software Engineering), que de vez en cuando gusta recordar y cuya idea de fondo en muchas ocasiones se olvida. Brooks (basándose en la descomposición que hizo Aristóteles del conocimiento) dividió en esenciales y accidentales las propiedades del software.

Esenciales o propiedades naturales e inherentes del software, sin las que el software no sería software, igual que sin cuatro ruedas un coche no sería un coche, y que son complejidad (el software es complejo por naturaleza), conformidad (el software debe cumplir con limitaciones arbitrarias impuestas por personas y reglas de negocio), modificabilidad e invisibilidad.

Y las accidentales, aspectos no inherentes, como el tipo de lenguaje de programación (el software podría construirse con Java o C#), el tipo de modelo de calidad de procesos, la marca del gestor de BBDD, etc., elementos y tecnología que cambian e incluso quedan obsoletos con el tiempo, asociados a la producción del software.

Con el tiempo, la profesión ido creando un amplio cuerpo de conocimiento en ingeniería software que nos ha enseñado la mejor manera de trabajar, afrontar o resolver problemas asociados a lo esencial o naturaleza del software, como, por ejemplo, a no utilizar el “go to”, la importancia de la ocultación de la información, el diseño orientado a objetos, las arquitecturas de capas, cómo estimar proyectos, el valor de las mejoras, economia software, patrones, etc. Pero estos, en demasiadas ocasiones, se olvidan, o desconocen, y se buscan, y se ofrecen, “balas de plata”, soluciones desde lo accidental (una determinada herramienta, entorno automático o CASE, cambiar a cierto lenguaje de programación, utilizar cierto el modelo de procesos, etc.).

En mi experiencia, la mayoría de los problemas del software parten de obviar los principios esenciales, y se incrementan al intentar solucionarlos exclusivamente desde la vía accidental. Como profesión debiéramos cuidar más el conocimiento esencial, la educación y formación en el mismo. El conocimiento accidental es necesario para poder trabajar, pero el esencial es necesario para además hacer un buen trabajo. El difundir y aprender el cómo trabajar correctamente con la parte esencial del software, ese basto conocimiento que existe y que hemos ido creando, es quizás uno de los principales retos de nuestra profesión.

Por cierto, como nota curiosa y de final alegre, en 2007 se realizó un taller retrospectivo en la OOPSLA (una importante conferencia sobre ingeniería software que se celebra todos los años) titulado «No Silver Bullet Reloaded«. Entre los ponentes estaba Martin Fowler (conocido entre otros por libros como refactoring, analisys patterns y architectural patterns), y quien si duda eligió la mejor vestimenta para la ocasión…

0 comentarios en “Del conocimiento esencial y del accidental”

  1. Pingback: Algunos retos de los profesionales del software | Javier Garzás

  2. Pingback: Documentar, de manera ágil, pero documentar | Javier Garzás

  3. Pingback: Errores clásicos en el desarrollo software | Javier Garzás

  4. Pingback: Algunos fallos en la Producción de software | Daniel Parente Blog

  5. Pingback: Algunos retos de los profesionales del software. La memoria histórica (2/4) - Javier Garzás, sobre calidad software y otros temas relacionados

  6. Pingback: El crece pelo universal, la dieta milagro, inglés con 10 palabras y el Ágil método repara todo - Javier Garzás, sobre calidad software y otros temas relacionados

Deja un comentario

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

Share This
Ir arriba