miércoles, 2 de noviembre de 2011

[8 de 97] Programar es diseñar.


Post publicado originalmente entre Mayo del 2009 y Enero del 2011 en mi anterior blog.
Pertenece a una serie sobre arquitectura de software, replicaré los comentarios ya que, a mi parecer, son lo más importante de la serie.

Puedes encontrar el listado de esta primera entrega en este enlace.

El axioma de hoy (tomado del libro 97 things Every Software Architech Should Know) dice:
"La programación es un acto de diseño"
Einar Landre. 

Einar Landre es un profesional del software con 25 años de experiencia como desarrollador, arquitecto, administrador y consultor.

Aquí buena parte del axioma:

Diseño
---

Kristen Nygaard, father of object-oriented programming and the Simula programming language, used to say: Programming is learning. Accepting the fact that programming or more precisely software development is a processes of discovery and learning and not a process of engineering and construction are fundamental to bring software practices forward. Applying the concepts of traditional engineering and construction on software development does not work. The problems have been documented and commented upon by leading software thinkers for more than 30 years. As an example, In 1987 Fredric Brooks JR stated in the "Report of the Defense Science Board Task Force on Military Software" that the document driven, specify-then-build approach lies at the heart of so many software problems.

So where should the software industry go and look for improving their practices? What about the industries involved in production of sophisticated mass-market products such as cars, pharmaceutical drugs or semiconductors?

In the article “What is software design?” Jack Reeves suggested that the only artifact of software engineering that satisfied the criteria for a design document, as such document is understood and used in classical engineering, is the source code. The manufacturing of the software is automated and taken care of by the compiler, build and test scripts.

By accepting that carving out source code is an act of design, not an act of construction we are in a position to adopt useful management practices that are proven to work. Those are the practices used to manage creative and unpredictable work such as developing a new car, a new medical drug or a new computer game. We talk about the practices of agile product management and lean production such as SCRUM. These practices focus on maximizing return-on-investment in terms of customer value.

For the software industry to capitalize on these practices we must remember: Programming is an act of design, not an act of construction.

---
Voy a iniciar la reflexión de este axioma listando, a manera de recordatorio,  los siguientes  principios de diseño.

Este listado esta basado en el material de estudio de la especialización: Patrones de diseño e interfaces de usuario gráficas  de la Universitat Oberta de Catalunya.
  • Bajo acoplamiento
  • Alta cohesión
  • Ley de Demeter
  • No repetición (Don´t repeat yourself)
  • Substitución de Liskov
  • Segregación de interfaces
  • Inversión de dependencias.
Cuando leí el axioma, mi primer pensamiento llegó a la lista anterior, y creo que esto refleja que:  cuando pensamos en diseño, en la mayoría de los casos evocamos los principios de diseño de software y pasamos por alto el concepto principal que incluye la oración: el diseño.

Creo que uno de los principales problemas que tenemos al momento de diseñar software es que, en nuestro afán de pasar a la codificación y sentirnos en terreno seguro, obviamos  algunas cosas.

Así que ahora, me apoyaré en la tercera acepción (de la vigésima segunda edición de la RAE) de la palabra diseño:

       3.  m. Concepción original de un objeto u obra destinados a la producción en serie. Diseño gráfico, de modas, industrial

Y para terminar de llenarnos de conceptos, una definición que aparece en la página 24 de la segunda edición en español del libro "Análisis y diseño orientado a objetos con aplicaciones" de Grady Booch:

Como sugiere Stroustrup, "El propósito del diseño es  crear una estructura interna (a veces llamada  también arquitectura) clara y relativamente  simple." 

Recalco pues, que según mi percepción y a riesgo de equivocarme,  buena parte de las complicaciones que tenemos para diseñar es que no logramos darle un significado profundo y amplio a la palabra.

Buscando referencias sobre este punto encontré una entrada en un blog con el título ¿Qué es diseñar?  y la reflexión del autor, creo, nos señala un poco el camino sobre lo que debemos tener en mente cuando nos topemos con esa palabra.

       Diseñar es elegir, elegir es renunciar.

Podríamos complementarlo así:

       Diseñar es elegir (según nuestros conocimientos y según el escenario), elegir es renunciar (a otras posibles soluciones, asumiendo que quizá no estemos ofreciendo  la solución perfecta, sino,  la más adecuada)

Diseñar pues exige algo más de lo que en ocasiones (en principio) podemos concebir.

¿No creen?

En lo que, (como decimos en México, evocando los teléfonos de moneda del siglo pasado que recibían monedas de 20 centavos, para afirmar que no hemos entendido algo), nos cae el veinte.
Dejemos que Dilbert nos dé su opinión    XD


dilbertsoftwarerequirements
Buena semana a todos!!!

RuGI
Isaac Ruiz Guerra.

Comentarios:

Tal vez si hubiera un conjunto de conceptos y significados aceptados por la mayoría sería más fácil pisar estos terrenos. Pero en efecto, siendo programador de corazón siempre defenderé que precisamente programar es un acto de diseño. Sin embargo, un llamado "arquitecto o ingeniero de software" y sobretodo los profesores de sistemas dirá que programar es puramente la construcción de lo que ya está diseñado y bien medido; que se meten programadores y diseños a una máquina (oficina) y al tiempo estimado sale el producto (software) ya hecho.

Enviado por Jesfre en julio 06, 2009 a las 06:21 PM CDT #
---
Disclaimer: Atención Ladrillo!

Este axioma ha tocado uno de mis formas favoritas de tocar las narices a "arquitectos" y "analistas" (aunque según mi nómina yo sea un "analista" ;-)).

Creo que hace ya un año que me encontré con el artículo original del señor Reeves por internet (y es del 92! mea culpa :-() y cambió mi perspectiva del código. El mejor sitio para consultarlo es http://www.developerdotstar.com/mag/articles/reeves_design_main.html , donde también está la continuación de dicho artículo, donde responde las críticas; así que si alguien no está de acuerdo, que primero se lea la respuesta de don Reeves (que será 1000 veces mejor a la mía ;-)). En mi descargo quiero decir que no soy el único que no se lo leyó en el 92 (de poco me hubiera servido cuando aún sólo había tirado unas líneas de basic de un msx de mi primo), porque muchos de los conceptos que propone, se están poniendo AHORA de moda (incluso ya habla de Kaizen y Lean aplicado al software!).

La respuesta es sencilla: EL CÓDIGO ES EL DISEÑO. Si quieres, por analogía con otras ingenierías, el código es el plano y el producto final sería uno o varios procesos ejecutándose sobre un sistema operativo. Osea, de que sirve un código que no compila? De nada, es como un plano de arquitectura con todas las medidas erróneas. Ni siquiera podría llegar a compararse con un edificio mal construído (que podría ser un PROCESO con un memory leak, por ejemplo ;-)). Como ya digo, don Reeves lo explica 1000 veces mejor, asi que los interesados, que se lean el artículo.

Sólo quiero hablar de lo que psicológicamente supone considerar al software como el DISEÑO (o lo que me ha supuesto a mi en mi trabajo diario):

1. MANTENIBILIDAD. ¿Cuantos arquitectos presentarían el plano de un edificio con tachones, manchas de café y agujeros de cigarrillos? O mejor ¿que pensaríamos de ellos como clientes? ;-). Si piensas en el código como diseño, sabes que habrá otra gente que mire tu plano, asi que procuras ser limpio (o cuando eres sucio, porque no has tenido un buen dia, lo avisas a base de FIXME's y XXX's ;-)). Dejas de pensar en el código como "algo" que se ejecuta, sino como "algo" que se lee.

2. TESTEO. ¿Cruzarías un puente al que no le hubieran hecho una prueba de carga, sólo porque el ingeniero ha creado unos planos magníficos y tiene un documento de 800 páginas de ecuaciones? Pues señor "arquitecto" guardese usted su UML, que hasta que el código HAYA SIDO TESTEADO NADIE PUEDE ESTAR SEGURO DE QUE REALMENTE FUNCIONA. Es más, incluso cuando testeas, tampoco puedes estar seguro, asi como tampoco puedes estar seguro de que el puente soporte lo mismo si sopla un viento huracanado; pero por lo menos tienes un % más alto de probabilidad de que lo aguante que si no lo haces.

3. CORAJE. Pues si. Estoy teniendo la oportunidad de trabajar con gente procedente de distintas empresas y es sorprendente que es lo que esperaban de un "analista": un tío que se dedica a "UMLear" arquitecturas y que NO PROGRAMA. Osea, se esconde detrás de un "documento de diseño", y son los programadores los que tienen que implementar las paridas que se le hayan ocurrido al susodicho. Y si, digo paridas, porque si consideras el código como diseño, ¿que es entonces un documento con imágenes? Pues el esbozo a mano alzada que hace el arquitecto en una servilleta de papel cuando le proponen un proyecto. Ni más ni menos. Una arquitectura que no tenga un esqueleto (como otro de los axiomas de los que ya has hablado) probado y testeado NO ES NADA. Niente. Ezer ere ez. No llega ni a la categoría de plano de construcción. Así que le echas coraje, y demuestras con código y tests que tu esbozo funciona o NO HAS HECHO NADA para que el proyecto prospere.

Esos "analistas" y "arquitectos" son los que yo considero intrusos en la profesión, aunque tengan el título que empieza por infor y acaba por mática ;-).

Asi que, ¿estoy diciendo que UML y la documentación no sirven para nada y es mejor no hacerla? Pues no. Como bien indica el señor Brooks en el mil veces mal citado artículo "No Silver Bullet", el verdadero problema es la "esencia aristotélica": trasladar la solución de un problema humano a los sistemas software. Podemos hacer cualquier cosa, no existe ninguna ley de la gravedad en el software, y una aplicación puede estar en diez millones de estados distintos. Asi que la documentación nos sirve como una interfaz de acceso al código: en otras disciplinas no es necesaria esa interfaz para leer un plano, pero en la nuestra, por su propia naturaleza, si lo es.

Y hay que tener coraje para no entregar un documento de diseño, hasta que hayas demostrado mínimamente que realmente puede usarse para entender tu diseño real: el código. Sobre todo, cuando tus clientes, abotargados por tantos años de malas prácticas, sólo se quedan contentos si el documento de diseño sobrepasa el terabyte ;-)

4. AGILIDAD. Y no hablo de "métodos agiles" (aunque la idea es la misma ;-)). Sólo existe una constante, y esa constante es el cambio... toma koan ;-) Pero es que es la pura realidad. Si el código es el diseño, a lo largo de toda la vida del proyecto estás diseñando, y como siempre diseñas, te estás adaptando a los cambios. Y te preocupas de poder cambiar el código tranquilamente sin romper nada (con tests, limpieza y dependencias mínimas) porque sabes que seguro que lo cambiaras. O ¿acaso el arquitecto no cambia el plano del edificio si encuentran una desconocida bolsa de gas en el subsuelo que nadie había descubierto hasta empezar a perforar?

Acabo ya, que me he pasado tres pueblos ;-), pero resulta curioso ver como la gente que más se queja del estado de nuestra profesión, suele ser la más reticente a un cambio de mentalidad. Lloriquean por las esquinas porque les han cambiado los requisitos, o protestan airados porque no tienen un documento de diseño que resuelva todos y cada uno de los problemas que se les van a presentar. Presentan su código, después de haber hecho tres pruebas a mano, y el error siempre será de las librerías, la plataforma o del sistema operativo. Espero que esta crisis los barra del sector, pero aún estamos en pañales y eso no sucederá.

Salu2 y perdón de nuevo por el tocho.

Enviado por Ibon Urrutia en julio 07, 2009 a las 02:53 PM CDT #
---
Estoy bastante de acuerdo con vosotros, el código es el diseño.

Nos cuesta creer que en el desarrollo de software no hay obreros, guste o no, todos los programadores son arquitectos.

Esto no quita que haya más niveles y personas de supervisión, de captura de requisitos, de conocimiento profundo del problema etc etc.

Enviado por jmarranz en julio 07, 2009 a las 03:11 PM CDT #
---
Hombre Ibon!!!.......

Mil gracias por este sublime "ladrillo" ;)

Esperemos que poco a poco todos vayamos tomando conciencia (y mucha humildad) para dar por válida algunas cosas que nos tardamos en aceptar.

Y coincido contigo: "apenas estamos en pañales"... a manera de exclusiva [!y que nadie se entere ;) !!] el próximo axioma hablará en parte de eso!!

Que sea una buena semana!!!

¡¡¡ Saludos !!!
RuGI

Enviado por RuGI en julio 07, 2009 a las 03:59 PM CDT #
---
Este post ha superado mis espectativas, tanto por las reflexiones de Rugi como de Ibon.

Felicitaciones, sus aportes me van ayudando a ser mejor profesional. Gran talento de ambos.

Enviado por Germán G. en julio 11, 2009 a las 12:24 AM CDT #


--------------------------------------
Créditos:
La foto es de: leograttoni
http://www.flickr.com/photos/23132567@N03/2851222835/
Dilbert es una marca registrada de Scott Adams.
-------------------------------------

No hay comentarios:

Publicar un comentario