Las siguientes observaciones consideran algunos momentos de la historia, de esa actividad peculiar y un tanto tierna del quehacer humano, esa que incluye la expresión algorítmica con lógica simbólica, y se ensancha en el diseño a gran escala de programas para computadoras digitales, también conocido como “programar”.
Primero, una aclaración, no pretendo explícitamente plantear objetivos adicionales alrededor de la programación; tales como: adquirir influencia en medios académicos, cautivar audiencias en algún mercado, resolver el defecto en tu programa de esta semana, hacerte millonario por la venta de software u organizar un proyecto con 25 programadores y 100 gerentes. Sino enfocarme en la actividad como tal, considerando un objetivo simple: programas correctos.
Los programas correctos típicamente incluyen otros adjetivos, por ejemplo: completos, robustos, extensibles, eficientes, escalables, compatibles, fáciles de usar y oportunos. En tres palabras: programas bien diseñados.
Por tanto, el planteamiento para una fundamento sólido, considera múltiples factores que se relacionan con el éxito en software, y que agrupo1 en cuatro dimensiones: personal, proceso, producto y tecnología. Además, me ayuda a dormir tranquilo por las noches.
Si todavía estas conmigo, entonces asumo que compartimos percepciones; es decir, te gusta diseñar y construir con tus propias manos, mecanismos que funcionen, y que funcionen bien para deleite de los usuarios.
El Practicante debe ser el amo, y el método el esclavo. No al revés.
Al pensar en un programa correcto, recuerdo la definición que propone Bertrand Meyer2 y que traduzco así: “Exactitud es la habilidad de los productos de software para realizar sus tareas precisas, tal como lo define su especificación”.
Diseñar programas correctos, involucra arte, ciencia, matemáticas e ingeniería, con no muy claros límites entre dichos aspectos; de tal manera, que al estado actual de la actividad, se le puede comparar con los gremios de artesanos en la Edad Media. Por ejemplo, la manera de diseminar las condiciones sine qua non del oficio, sólo sucede al observar a otro practicante profesional (alguien que también vive de hacer programas correctos).
En la historia podemos encontrar varias propuestas para organizar y regular el diseño sistemático de programas; que se han documentado en forma de reglas, procedimientos y técnicas, es la metodología. La práctica de ésta, puede ayudar a diseñar programas correctos, pero debemos tener el debido cuidado de no considerar algún método en particular como el único y verdadero camino para salvarse de los descalabros en proyectos de desarrollo. Cada proyecto se puede considerar como irrepetible por la combinación singular de factores que forman su contexto, por lo que no hay un solo método que sea como anillo al dedo para todos los proyectos. Regularmente tiene sentido confeccionar un método para cada proyecto como una combinación de varios elementos ajustados a la necesidad inmediata. Alistair Cockburn presenta muy bien esta idea al decir:
“The ultimate point is that one methodology cannot possibly be the ‘right’ one, but that there is an appropriate, different way of working for each project and project team”
Así que te invito a conocer, y practicar nuevos métodos para averiguar: cómo se siente desde las trincheras. Y de esta manera, saber cuándo aplica cada método; evitando la situación: “si la única herramienta que conoces es un martillo, todo te parecerá un clavo”.
Por lo tanto, para diseñar programas correctos, puedes usar elementos de varios métodos, tantos como hayas practicado, ya que el objetivo no es servir a un amo llamado método, sino al revés, los métodos están ahí para servirte a ti, que eres practicante.
Unas consideraciones adicionales cuando elijas métodos en los que invertirás tiempo y esfuerzo: fíjate que el método incluya elementos para identificar, en primer lugar, cuál es el verdadero problema del usuario, cómo obtener una visión compartida del mismo, y de su solución. Además, investiga si las personas que proponen el método son practicantes profesionales y presentan su método de una manera descriptiva, es decir, incluyen el “cómo hacerlo” y no sólo prescripciones desde el punto de vista del “qué deberías hacer”.
Referencias
1. Las personas en el diseño y programación orientada a objetos.
www.rosenblueth.mx/interfar/vol1num3/doc/vol1num3-48.htm
2. Object Oriented Software Construction. 2nd edition. Bertrand Meyer. ISBN: 01362-9155-4
3. A Methodology per project
alistair.cockburn.us/crystal/articles/mpp/methodologyperproject.html
- Log in to post comments