Pages Menu
Categories Menu

Posted by on May 19, 2009 in buenas prácticas, errores y riesgos, hitos historicos, profesión, Reseñas esenciales | 1 comment

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…

Javier Garzás

Javier Garzás

Ph.D. en informática, Postdoctorado en la Carnegie Mellon (EE.UU) e Ingeniero en Informática.

Primera vez que me tocó hacer una gestión Ágil en una empresa... año 2001. Desde entonces he trabajado en, o para, más de 90. Y he formado a más de 2000 alumnos.

También soy profe de la Universidad Rey Juan Carlos.
Javier Garzás

1 Comment

  1. Hola Javier, excelente artículo, de verdad que lo disfruté mucho y todas las referencias informativas. Gracias

Trackbacks/Pingbacks

  1. Algunos retos de los profesionales del software | Javier Garzás - [...] o a veces nos creamos cosas que desde hace tiempo la experiencia dijo que no funcionaban (“silver bullets”) o…
  2. Documentar, de manera ágil, pero documentar | Javier Garzás - [...] software, evitar que importantes errores en la gestión de proyectos software se sigan repitiendo, separar lo esencial de lo…
  3. Errores clásicos en el desarrollo software | Javier Garzás - [...]  Negociaciones y el “tira y afloja” (entre, por ejemplo, desarrollo y comerciales) 7.    El síndrome de la bala de…
  4. Algunos fallos en la Producción de software | Daniel Parente Blog - [...]  Negociaciones y el “tira y afloja” (entre, por ejemplo, desarrollo y comerciales) 7.    El síndrome de la bala de…
  5. Algunos retos de los profesionales del software. La memoria histórica (2/4) - Javier Garzás, sobre calidad software y otros temas relacionados - [...] software añadiendo más personas a un proyecto ya en marcha. O a que aún se siga creyendo en los…
  6. 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 - [...] otros muchos, ya lo dijo Brooks en el 75 (te recomiendo este post), que muchas veces, nos ofrecen, o…

Post a Reply

Tu dirección de correo electrónico no será publicada.

Share This