(1) https://agilidad.blogspot.com/

(2) https://formularsoftware.blogspot.com/

(3) https://retrodidacta.blogspot.com/

(4) https://medium.com/@marcodorantes

Para mí —un programador de computadoras— es un deleite cada intento de poner por escrito mis pensamientos sobre lo que me interesa comunicar a una persona o, por otro lado, cada intento por controlar el comportamiento de una computadora al escribir líneas de código ejecutable. Escribir para procesadores basados en carbono (cerebros humanos) y escribir para procesadores basados en silicio (cerebros electrónicos: microprocesadores digitales) es algo muy delicioso para mí.

Ambas actividades tienen destinatarios muy diferentes. Aunque tienen en común un rasgo que las hace igualmente atractivas para mí: complejidad. En particular, un tipo de complejidad que no es accidental, sino que es parte inherente de su esencia. Pero no la esencia del acto de escribir, sino la esencia del destinatario hacia quien escribo. Una complejidad, por tanto, que no puede ser eliminada, tan sólo regulada o conducida.

En retrospectiva, fue hasta años después de haber terminado una carrera reglada por una institución académica que caí en cuenta de que el ejercicio de la cibernética –en un sentido amplio– es el nombre propio de lo me ha estado apasionando desde la adolescencia. Tal carrera tuvo la palabra “cibernética” en su título, aunque su contenido abarca muy muy poquito de cibernética —si se compara con el cuerpo de conocimiento científico actual sobre cibernética (en general, la comunicación y el control entre humanos, entre máquinas y entre sistemas complejos adaptativos diversos)—.

☛ Mi punto principal, en general, es que cada uno dentro de los grupos técnicos de cada proyecto (e.g., Scrum Development Team) necesita mejorar en su práctica de pensar arquitecturalmente desde su área de competencia. De esa manera lograremos aproximarnos a mejores soluciones ante los problemas de cada proyecto.

Mi intención no es pretender una respuesta que cierre la pregunta inicial, sino nutrir posibles conversaciones y discusiones sobre pensar arquitecturalmente con cualquiera interesado en el tema. La clave es no sólo incluir miembros de los grupos técnicos (e.g., Scrum Development Team), sino también incluir miembros del negocio en cuestión (e.g., Scrum Product Owner). Es decir, pensar arquitecturalmente no sólo es relevante para grupos técnicos de TI, sino principalmente es relevante para el diseño técnico —i.e., detallado— de las estrategias comerciales de los negocios hacia sus propios clientes (lo cual sería parte de la carnita rescatable de la así llamada “arquitectura empresarial”).

¿Cómo pensó el grupo de albañiles, arquitectos e ingenieros de, por ejemplo, la Torre Latinoamericana –en la Ciudad de México– para que se mantuviera en pie todos estos años? ¿Cuáles valores, principios, prácticas y hábitos fueron parte de su ambiente profesional como para funcionar como grupo de trabajo con tales resultados? El resultado de su modo de pensar y actuar ha permitido que muchos habiten tal edificio por muchos años sin preocuparse de si hoy permanecería en pie. Con su ambiente profesional no sólo edificaron un inmueble material, sino que edificaron bases sobre las cuales se apoyó la confianza de todos en lo que hacían.

Antes pensaba que crear software era una disciplina de ingeniería y que todo proyecto debería tan sólo seguir prescripciones ya establecidas y probadas. Pero después de indagar comprobé que no debe, ni puede, ser así para cada proyecto. Por lo cual, el ejemplo anterior me sirve para pensar más en cómo un ambiente profesional (i.e., conjunto de valores, principios, prácticas, hábitos, etc.) puede ser un caldo de cultivo para ese tipo de resultados.

Una inferencia obvia es que un ambiente profesional debe enfocarse en edificar confianza en lo que se plantea y se hace ahí. Una base sólida sobre la cual apoyar la confianza es la evidencia material verificable, no sólo las palabras y las buenas intenciones. Si de confianza se trata: Lo importante no es quererlo, creerlo o decirlo —eso cualquiera lo hace—, sino demostrarlo. Así se está en mejor posición para cimentar una confianza duradera.

Las profesiones confiables hoy en día se derivan de la confianza que aportan los procesos de las ciencias. Por lo que regresar a los básicos del pensamiento científico es parte de mejorar una profesión hoy en día y de mejorar los ambientes en donde se ejerce cualquiera de las profesiones contemporáneas. Pero, por favor, debe quedar claro, aquí no me refiero al adefesio de “el método científico” que se expone en los sistemas escolarizados tradicionales. Eso sólo existe en las [j]aulas de dichas escolarizaciones. Aquí me refiero a cada perspectiva adulta, amplia, profunda y compleja que del pensamiento científico se ha evaluado desde la filosofía de la ciencia, i.e., epistemología.

Para no extenderme más aquí, intentaré provocarle la curiosidad, amable lector, diciendo que la confianza en las ciencias inicia con la destreza para distinguir entre conocimiento y meras opiniones.

Además, para ser explícito, propongo que pensar arquitecturalmente está ligado de manera directa con el autocultivo necesario para realizar estrictos escrutinios críticos. Pero esa relación no agota los modos de pensamiento relacionados. Los modos de pensar en la categoría del orden superior, i.e., la metacognición, cooperan entre sí necesariamente: el pensar creativo, el pensar crítico, el pensar solidario –por mencionar algunos– interactúan por demanda en un pensar arquitectónico.

Una de las palabras de moda, entre otras, parece ser “ágil”. No pocos publicistas abusan de esa palabra al adherirla sobre aquello que quieren vender. Si su objetivo ahora fuese vender espejos, entonces a los mismos espejos de siempre, los mismos que vendían, por ejemplo, con la etiqueta de “orientados a objetos”, ahora los anuncian como “espejos ágiles”. Algo similar puede ocurrir con otras palabras de moda, como “microservicios”.

Por ejemplo, recién inicié una lectura crítica del libro a continuación: Agile People: A Radical Approach for HR & Managers (That Leads to Motivated Employees). Mi evaluación preliminar del mismo es favorable. Aunque, como la palabra “agile” está en el título, evaluaré más a fondo si se trata del artilugio de marras para vender más libros o sí discurre sobre algo substancial. Además, un riesgo muy peligroso es que su título sea malinterpretado y termine por alentar prejuicios y etiquetas sobre las personas: “esta persona es ‘ágil’ o aquella otra persona no es ‘ágil’” —¿ve usted las peligrosas implicaciones de que alguien incompetente tome decisiones con base en tales prejuicios?

«El hábito no hace al monje» —dicen por ahí. Digámoslo así: una es la apariencia y otra es la realidad subyacente. Una es la forma y otra es la materia de dicha forma. Ambas categorías son partes de un todo y ambas son relevantes, en tanto no se tome lo uno por lo otro. Una cosa es el semblante superficial, contingente; y otra cosa es la substancia necesaria, la que hace emerger aquel semblante. Si se enfoca en lo substancial, entonces puede usted planear que el semblante emergerá por sí sólo. Si se enfoca sólo en lo superficial, e.g., sólo en el uso de las palabras “correctas” sin el comportamiento correspondiente, entonces podría usted estar construyendo sobre arena y entonces no se sorprenda de que lo substancial nunca ocurra en los hechos de la realidad objetiva.

Le invito a iniciar conversaciones sobre los rasgos profesionales de la creación de soluciones de negocio basadas en software y –aún más importante– le invito a mantener esas conversaciones abiertas, sin intentar cerrarlas y sin considerar las cuestiones clausuradas por completo.

Por fortuna yo no perdí tiempo estudiando filosofía en ninguna institución. Me hubiera sucedido lo que a Jonathan Keats, lo cual es lo mismo que ya he hecho en varias ocasiones: abandonar instituciones que pretenden tener el monopolio de la verdad ya sea en política, historia, ciencia, religión o en otras áreas de mucho interés para mí; como la creación de soluciones de negocio basadas en software.

What the World Needs is More Curious Amateurs.

El otro día fui a esta conferencia sobre la vida y, principalmente, la obra literaria de Antoine de Saint Exupêry.

¿Será descabellado decir que para mí ese tipo de material representa parte de mi “capacitación” profesional en creación de soluciones de negocio basadas en software?

Dicho así, sin justificación, no es claro y cabe la duda sobre cómo estarían relacionados esos dos temas, lectoescritura y creación de software, tan dispares en apariencia.

Por un lado, he visto lo que la lectoescritura le puede hacer a una persona en términos de transformarle la mentalidad —para bien o para mal, pues el resultado no siempre sería miel sobre hojuelas—. Aquí opera la destreza básica para interpretar un texto: entre mayor destreza, más jugo se le saca al texto. Por lo que una interpretación a la ligera no es lo mismo que una interpretación más pensada.

La obra «El principito» de de Saint Exupêry es un caso de excesiva mercantilización y de muchas interpretaciones a la ligera. No es una obra escrita para infantes, sino una catarsis melancólico-existencial repleta de añoranza. Por lo que me ha interesado tomarla, entre otras obras, para ejercitar mis capacidades interpretativas o hermenéuticas e intentar sacarle más jugo. Por ejemplo, ¿quién o qué simboliza la rosa? ¿Qué o quién es el zorro? ¿Y el cordero? Etc. Hay variedad de posibles respuestas en función del sistema de interpretación utilizado. Nuestra destreza interpretativa, por tanto, depende de cuántos sistemas de interpretación conozcamos y seamos capaces de aplicar a textos concretos.

Por el otro lado, creación de software como profesión tiene textos fundacionales que son muy importantes y que debemos interpretar cada vez más y mejor. De eso, en parte, depende un mejor entendimiento de nuestra profesión y del jugo que le sacamos a la aplicación práctica de las ideas en esos textos. Tan sólo por mencionar unos ejemplos de esos textos:

(1) The Art of Computer Programming (TAOCP)

(2) Structure and Interpretation of Computer Programs, Second Edition

–Editorial

–Curso

(3) Managing the development of large software systems: concepts and techniques

☛ A este último texto se le atribuye establecer el inicio histórico del modelo en cascada para desarrollo de software; sin embargo, tal texto fue interpretado muy a la ligera y en realidad constituye —según el propio autor— una refutación en contra de dicho modelo.

Adivine usted qué, amable lector: lo mismo aplica para los textos que contienen ideas clave en temas como Agile, o Scrum, o Domain-driven design, o micro-servicios, o IT social sentiments, o Machine Learning, o Big Data, etc.

Le pregunto: ☛ ¿Logré explicar algo, en general, del porqué es relevante, profesionalmente, mejorar nuestras destrezas para interpretar textos?

¿Qué clase de cambios son pertinentes en una transformación cultural para la mejora en creación de soluciones de negocio basadas en software?

Dado el tipo de trabajo que está íntimamente involucrado en los procesos de dicha creación —es decir, el trabajo de tipo intelectual—, una clase pertinente de cambios, por ejemplo, serían cambios en los procesos de aprendizaje. Es decir, cambios en los procesos por los cuales las ideas se hacen parte de la mentalidad, y de la conducta, de las personas involucradas. ☛ Distinción relevante: aquí me refiero al aprendizaje, no me refiero a la enseñanza.

El aprendizaje está, principalmente, en manos del aprendiz. Por lo que el cambio particular que aquí propongo es intentar una mayor conciencia por parte del aprendiz sobre sus propios procesos de aprendizaje. ☛ Si el aprendiz logra una mayor conciencia de los tipos de pensamiento aplicables durante su recorrido en un tema dado, entonces esa mayor conciencia de sí mismo podría ayudarle a sopesar las oportunidades para aplicar adecuadamente, por ejemplo, el pensamiento dogmático, el pensamiento crítico y el pensamiento creativo. Ver referencia: El progreso de un aprendiz, más adelante.

Hay teorías del aprendizaje que distinguen entre datos, información y conocimiento pues, aunque están muy relacionados entre sí, en realidad son distintos en la estructura cognitiva del aprendiz. Los dos primeros se pudiesen transmitir por medio de los imperantes y cortoplacistas esquemas escolarizados, pero el tercero no es transmisible y lograrlo está por completo en manos del aprendiz.

El progreso de un aprendiz

—Edición 2015: https://agilidad.blogspot.mx/2015/01/el-progreso-de-un-aprendiz.html

—Edición 2009: https://blogs.msdn.microsoft.com/destreza/2009/10/30/el-progreso-de-un-aprendiz/

——

Con respecto al diseño de software, que es el aspecto más fascinante para mí de lo que hacemos como programadores profesionales, permíteme comentarte mis impresiones y conclusiones actuales acerca de esta actividad. Por supuesto, estas conclusiones están sesgadas por mi enturbiado entendimiento, pero después de estudiar la experiencia de algunas luminarias en nuestro campo, e intentar practicar sus lecciones, encuentro que dichas conclusiones tienen sentido para mí.

I. El resultado de la actividad 'diseño'

El resultado material de la actividad de diseño debe ser algo ejecutable. Cualquier cosa menos que eso es pura estimulación mental.

II. Arquitectura de software

Todos los aspectos, de alto y bajo nivel, de nuestro diseño están expresados, implícita o explícitamente, en la arquitectura del software. Aunque “arquitectura de software” todavía es un término difuso, una exposición adecuada de arquitectura de software es la de Philippe Kruchten «The 4+1 View Model of Architecture».

The 4+1 View Model of Architecture

https://www.computer.org/csdl/mags/so/1995/06/s6042-abs.html

IEEE Software November 1995 (Vol. 12, No. 6)

https://www3.software.ibm.com/ibmdl/pub/software/rational/web/whitepapers/2003/Pbk4p1.pdf

https://www.rational.com/media/whitepapers/Pbk4p1.pdf

En resumen, la arquitectura de software considera 5 vistas o categorías, agrupadas por su naturaleza en:

Conceptual:

Vista Lógica (clases, módulos y subsistemas)

Vista Concurrente (procesos y threads)

Física:

Vista de Componentes (medios para empaquetar los elementos de la Vista Lógica: assemblies, DLLs)

Vista Distribuida (comúnmente llamada infraestructura de cómputo: servidores que contienen los elementos de la Vista de Componentes)

Funcional:

Vista de Casos de Uso. Ésta gobierna a todo lo que puede existir en las otras vistas; en otras palabras, nada debe existir si no aporta a soportar la funcionalidad del software

III. El código fuente es el diseño detallado del software

El diseño de alto nivel puede consistir de diagramas que expresen aspectos de las diferentes vistas de Kruchten, pero el diseño detallado es el código fuente. En software, nuestros planos detallados es un documento técnico llamado comúnmente «código fuente». Dichos planos de nuestro producto son entregamos al constructor del producto: el compilador o traductor a código ejecutable.

Philippe Kruchten, Jack W. Reeves y otros tienen algunas ideas al respecto:

What is Software Design? by Jack W. Reeves

https://www.bleading-edge.com/Publications/C++Journal/Cpjour2.htm

The Nature of Software: What's so Special About Software Engineering? by Philippe Kruchten

https://www.ibm.com/developerworks/rational/library/content/RationalEdge/oct01/TheNatureOfSoftwareOct01.pdf

https://www.therationaledge.com/content/oct_01/toc.html

From Craft to Science: Searching for First Principles of Software Development by Koni Buhrer

https://www.ibm.com/developerworks/rational/library/content/RationalEdge/dec00/TheRationalEdgeDec00Issue.pdf

https://www.ibm.com/developerworks/rational/library/content/RationalEdge/jan01/FromCraftToScienceJan01.pdf

https://www.therationaledge.com/content/dec_00/f_craftscience.html

IV. Decidir es diseñar

Diseñar requiere decidir constantemente, diseñar es decidir. Decidir sobre los aspectos del diseño detallado, decidir sobre los aspectos de diseño de alto nivel, e incluso decidir que no vamos a decidir nada todavía sobre alguna propiedad particular del software; es decir, vamos a diferir dicha decisión.

Martin Fowler habla acerca del diseño en:

Is Design Dead?

https://martinfowler.com/articles/designDead.html

What's a Model For?

https://www.martinfowler.com/distributedComputing/purpose.pdf

https://martinfowler.com/articles/purpose.pdf

V. Diseño estable y emergente

Diseñar requiere consideración de los principios que gobiernan y sustentan la arquitectura de software; como dice Bertrand Meyer, los aspectos a gran escala de la arquitectura de software se encomiendan o están sustentados en los aspectos de bajo nivel o escala detallada (código fuente). Si estos aspectos no obedecen a principios coherentes y de estilo, entonces difícilmente se logran los aspectos a gran escala.

Existe un cuerpo de conocimiento importante acerca de diseño orientado a objetos, con reglas que representan esos principios coherentes y de estilo:

Principles Of Object Oriented Design

https://c2.com/cgi/wiki?PrinciplesOfObjectOrientedDesign

Las recomendaciones del maestro Stroustrup agregan perspectivas importantes:

Bjarne Stroustrup's C++ Style and Technique FAQ

https://www.stroustrup.com/bs_faq2.html

https://www.research.att.com/~bs/bs_faq2.html

Las prácticas básicas son esenciales. Steve McConnell, ex-programador de Microsoft, tiene buen material al respecto:

Code Complete: A Practical Handbook of Software Construction

https://www.stevemcconnell.com/cc.htm

Rapid Development: Taming Wild Software Schedules

https://www.stevemcconnell.com/rd.htm

La técnica de factorización representa una excelente forma para mantener un diseño estable y flexible:

Refactoring

https://www.refactoring.com

VI. Control empírico del proceso de diseño

Un método de diseño es intrínsecamente iterativo e incremental. Se adhiere a un proceso 'gestalt'; es decir, no puedes terminar de diseñar software si primero no lo programas, y al mismo tiempo no puedes programar software si primero no lo diseñas.

Existen métodos sistemáticos de diseño y programación, Martin Fowler habla acerca de algunos métodos actuales:

The New Methodology

https://martinfowler.com/articles/newMethodology.html

Continuous Integration (no daily build)

https://martinfowler.com/articles/continuousIntegration.html

VII. Método sistemático de diseño

Un método sistemático de programación consiste de al menos tres partes:

a. Una notación — el énfasis aquí es contar con un conjunto de conceptos de diseño que guarden coherencia y que puedan ser expresados por medio de dicha notación. Actualmente está de moda UML y es importante tener mentalmente disponibles sus conceptos para comunicar la arquitectura de software. Pero para el diseño detallado (código fuente) la notación más eficiente y efectiva sigue siendo el lenguaje de programación seleccionado.

En otras palabras, todo lo que se puede expresar en un diagrama de clases en UML se puede expresar en el código fuente; y mientras las herramientas de generación de código carezcan del nivel de abstracción suficiente para eliminar la necesidad de modificar el código generado, el diseño detallado seguirá siendo el código fuente en sintaxis del lenguaje de programación.

En el futuro, seguramente habrá las herramientas para expresar todos los aspectos del diseño detallado en una notación como UML, y entonces eso será nuestra nueva forma de código fuente.

b. Un proceso — actividades, roles y artefactos. Los mejores procesos son los que incluyen un ciclo cerrado de retro-alimentación que se ajusta a la naturaleza 'gestalt' del software.

Los artículos en el siguiente sitio tienen información relevante acerca de los procesos que varios programadores profesionales han sintetizado:

https://www.extremeprogramming.org

https://www.agilealliance.org

¿Qué es «Software craftsmanship»?

https://blogs.msdn.microsoft.com/destreza/2017/03/19/que-es-software-craftsmanship/

El potencial de los métodos ágiles de diseño está en la esencia del desarrollo cooperativo:

-Control empírico del proceso de desarrollo

-Comportamiento emergente o adaptativo

-Auto-organización

c. Herramientas — que soporten el conjunto de conceptos disponibles en la notación.

En la práctica, lo más eficiente y efectivo, si el objetivo es obtener software ejecutable, es usar las herramientas más simples que ayuden con la comunicación entre las personas en el equipo de desarrollo y entre los individuos y la computadora.

En otras palabras, una simple hoja de papel y lápiz, o un pizarrón, son más efectivas que costosas herramientas CASE. No menos importante, el compilador es la mejor herramienta para verificar el aspecto estático de tu diseño detallado, el compilador hará un análisis preciso de tus decisiones de diseño y te dirá invariablemente toda inconsistencia con su sistema de tipos.

Además, para verificar los aspectos dinámicos de tu diseño, un contexto de pruebas unitarias (unit-testing framework) te ayudará a obtener la retroalimentación para evolucionar tu diseño de forma coherente y concreta, satisfaciendo los aspectos de la Vista de Casos de Uso de tu arquitectura.

Kent Beck y Erich Gamma exponen el diseño de un contexto de pruebas aquí:

JUnit Cookbook

https://junit.sourceforge.net/doc/cookbook/cookbook.htm

JUnit A Cook's Tour

https://junit.sourceforge.net/doc/cookstour/cookstour.htm

Como dice Martin Fowler: «Never in the field of software development was so much owed by so many to so few lines of code».

https://www.junit.org

Contextos de pruebas para varios lenguajes de programación están disponibles aquí (incluyendo la versión en C++Builder que hice del CppUnit de Michael Feathers):

https://www.xprogramming.com/software.htm

En general, el material en este sitio provee buen material para el diseño y desarrollo de software:

https://butunclebob.com/

https://www.objectmentor.com/resources/articles

Los mejores métodos sistemáticos de diseño y programación actuales se derivan del trabajo de las siguientes luminarias:

Profesor Edsger Wybe Dijkstra

https://www.cs.utexas.edu/users/EWD/

Kristen Nygaard

https://www.mn.uio.no/ifi/english/about/kristen-nygaard/

https://www.ifi.uio.no/~kristen/

Ole-Johan Dahl

https://www.mn.uio.no/ifi/english/about/ole-johan-dahl/

https://www.ifi.uio.no/%7Eolejohan/

Alan Turing

https://www.turing.org.uk/turing/

Niklaus Wirth

https://www.inf.ethz.ch/personal/wirth/

https://www.cs.inf.ethz.ch/~wirth/

Donald E. Knuth

https://www-cs-faculty.stanford.edu/~knuth/

Bjarne Stroustrup

https://www.stroustrup.com/

https://www.research.att.com/~bs/homepage.html

Barbara Liskov

https://www.pmg.csail.mit.edu/~liskov/

https://www.objectmentor.com/resources/articles/lsp.pdf

David Lorge Parnas

https://www.computer.org/web/awards/mills-david-parnas

https://www.crl.mcmaster.ca/SERG/parnas.homepg

Tom DeMarco

https://www.systemsguild.com/tdm.htm

https://www.atlsysguild.com/GuildSite/TDM/Tom_DeMarco.html

Gerald M. Weinberg

https://www.geraldmweinberg.com

Larry Constantine

https://wiki.c2.com/?LarryConstantine

https://www.foruse.com/

Edward Yourdon

https://yourdon.com/

Meilir Page-Jones

https://www.construx.com/Employees/Meilir_Page-Jones/

Grady Booch

https://researcher.watson.ibm.com/researcher/view.php?person=us-gbooch

James Rumbaugh

https://en.wikipedia.org/wiki/James_Rumbaugh

Ivar Jacobson

https://www.ivarjacobson.com/

Bertrand Meyer

https://www.eiffel.com

VIII. Dimensiones en desarrollo de software

Los factores para la calidad del diseño y desarrollo de software se pueden agrupar en cuatro dimensiones:

a. Personas - el aspecto más importante y que aporta en general los factores determinantes para la calidad del software

El trabajo de Tom DeMarco y Tim Lister habla de esto desde hace ya muchos años

https://www.systemsguild.com/tdm.htm

First-Order Components in Software Development (People-oriented programming, non-linear response) de Alistair Cockburn

https://alistair.cockburn.us/Characterizing+people+as+non-linear,+first-order+components+in+software+development

https://crystalmethodologies.org/articles/panlc/peopleasnonlinearcomponents.html

Las personas en el diseño y programación orientada a objetos, de un servidor:

https://sg.com.mx/content/view/338

https://www.rosenblueth.mx/InterFAR/Vol1Num3/doc/Vol1Num3-48.htm

b. Proceso - las secciones VI y VII arriba.

c. Arquitectura de Producto - las secciones II, III, IV y V arriba.

Si un producto de software es correcto y robusto, es porque su código fuente tiene una adecuada administración de dependencias internas y conserva un adecuado sentido de estética y orden entre sus componentes; si un producto de software es modular y extensible es porque su código fuente tiene esas propiedades.

De ninguna otra manera es posible conseguir la calidad externa del software si no se atiende desde el principio la calidad interna. De esto trata el siguiente artículo de Bertrand Meyer:

Factores de la calidad del software

https://www.angelfire.com/dc/marcodorantes/Docs/CalidadDelSoftware.doc

d. Tecnología - aquí va todo el conocimiento específico de una plataforma de cómputo

IX. Pensamiento sistémico

Patrones y la teoría general de sistemas para el futuro (que ya paso) - existe material importante y un cuerpo de conocimiento fundamental que, sin importar lo que diga la mercadotecnia, es indispensable dominar para ser relevante en desarrollo de software ahora y siempre. Se trata de los patrones o mecanismos análogos de la teoría general de sistemas.

Comúnmente se escucha de patrones de diseño; sin embargo, esos pertenecen a una categoría, pero los hay por todos lados: patrones de proceso, patrones organizacionales, patrones arquitectónicos, patrones de implementación (idioms), patrones de análisis. Esto equivale a lo que la teoría general de sistemas estudia como situaciones análogas en relación a los procesos de pensamiento en los seres humanos.

Las herramientas de pensamiento para diseño moderno de software están disponibles y serán las bases para el software que estaremos usando en el cual se utilizan múltiples paradigmas para su diseño.

Algunas referencias al respecto:

•Patrones

Pattern Languages of Programs

https://hillside.net/conferences

https://jerry.cs.uiuc.edu/~plop/

Euro-Plop

https://www.europlop.net/

https://www.argo.be/europlop/Papers/Final/

Portland Pattern Repository

https://c2.com/cgi/wiki?PortlandPatternRepository

Patrones organizacionales de James Coplien

https://amzn.com/0131467409

https://www.bell-labs.com/cgi-user/OrgPatterns/OrgPatterns?CoplienOrganizationPatterns

•Diseño multi-paradigma

Generative Programming

https://amzn.com/0201309777

https://www.generative-programming.org/

https://www.prakinf.tu-ilmenau.de/~czarn/generate/engl.html

Aspect-Oriented Programming

https://www2.parc.com/csl/groups/sda/

https://aosd.net

Intentional Programming

https://www.intentionalsoftware.com

https://www.c2.com/cgi/wiki?IntentionalProgramming

Generic Programming

https://www.lafstern.org/matt/

•Acerca de la teoría general de sistemas

Cybernetics and Systems Theory

https://pespmc1.vub.ac.be/CYBSYSTH.html

«Este no es el final, ni siquiera es el comienzo del final; tal vez, tan sólo es el final del comienzo» —Winston Churchill

«Software craftsmanship» es creación de soluciones de negocio basadas en software con dos ideas básicas:

(1) Entrega frecuente de valor de negocio constante y sonante en las manos de clientes y usuarios. ‘Frecuente’ en la escala de semanas (entre una y cuatro), no más.

(2) Una profesión digna; es decir, una forma de vida profesional basada en sistemas de valores relativos al esfuerzo intelectual y cooperativo entre grupos de alto desempeño. Valores, por ejemplo, como los siguientes. (a) La autocrítica: 'es verdad que puedo estar equivocado'. (b) La mejora personal de la mentalidad propia; es decir, aprendizaje no como acreción de datos sino como cuestionamiento de las preconcepciones propias.

En español sería algo como «Software artesanal». No se refiere a lo ‘hecho a mano’, sino a la calidad en software que puede crearse con un conjunto muy particular de destrezas; es decir, artesanía no como objeto fabril sino como consecuencia de una forma de arte entendida propiamente como destreza.

Software craftsmanship suele ocurrir en un ambiente con sistemas de valores propicios para el esfuerzo de tipo intelectual y cooperativo. Otros valores compatibles con Software craftsmanship son, por ejemplo, simplicidad, comunicación, retroalimentación, empoderamiento, honestidad, etc.

De los valores personales suelen brotar principios profesionales.

«Aunque nada cambie, si yo cambio, todo cambia.» —Marcel Proust

Debo advertir que Software craftsmanship es una forma de vida; es decir, implica un conjunto particular de estilos para interpretar la realidad y para actuar en lo que respecta a la creación de soluciones de negocio basadas en software. Eso conlleva una variedad de requisitos. Por lo que quizá no es para todos, ni es algo “popularizable”. Software craftsmanship es una profesión; es decir, es la acción y el efecto de profesar una forma de vida basada en valores, principios, prácticas y hábitos compatibles con las dos ideas básicas ya mencionadas.

El devenir histórico de Software craftsmanship abarca tanto como la programación de computadoras contemporáneas, aprox. 70 años. A continuación remito algunas manifestaciones en años recientes y un par de notas propias al respecto:

(1) https://manifesto.softwarecraftsmanship.org/

(2) https://agilemanifesto.org/

(3) https://darkagilemanifesto.org/

(4) Software Craftsmanship: The New Imperative by Pete McBreen

(5) Dark Manifesto for Agile Software Development

(6) Dark Manifesto for Agile Software Development. Take 2

Algo más práctico que estar jugando a los espejitos y acrónimos de moda, en desarrollo de software se requiere indagar en las contribuciones científicas que, desde hace décadas, ofrecen buenas teorías y prácticas de las que ahora nosotros podemos hacer síntesis.

Lo siguiente es un breve preliminar al contexto de mi propuesta para considerar dentro de las estrategias de una Dirección contemporánea de sistemas:

Testability — quality of being testable or verifiable.

Testeabilidad | Testeable — posibilidad de ser comprobable o verificable o contrastable.

Es una propiedad arquitectónica emergente; es decir, regida por los principios propuestos por la teoría general de sistemas (cibernética). Como tal, no es una propiedad básica de ninguna de las partes de un sistema complejo o reductible a las propiedades de las partes, sino sólo es observable como propiedad de la suma de las partes. Por analogía, lo húmedo no es propiedad de ninguna molécula individual de H2O sino sólo es una propiedad de la suma de esas moléculas.

Para sistemas computacionales, y en específico para creación de soluciones de negocio basadas en software, puede ser diseñada como propiedad de cualquier alcance en tanto pueda delimitarse debidamente. Por ejemplo, puede ser diseñada como propiedad tanto de un requerimiento de negocio como de una especificación (funcional o no funcional), así como de una capacidad general de negocio o de una familia de soluciones, o un subsistema, un módulo, una clase, o una operación individual específica.

Delimitar el alcance debidamente significa poder identificar un subconjunto funcional completo liberable a producción (sección vertical completa o “rebanada de pastel”) que pueda ser contrastable contra un subconjunto correspondiente de la solución de negocio o valor de negocio esperado; es decir, que se elabore a priori o en paralelo un subconjunto correspondiente de verificaciones o comprobaciones que sean testigos de la capacidad del alcance delimitado.

Entre las condiciones para esta propiedad emergente, entre otras, está la estructura del alcance delimitado; es decir, la estructura de la solución permite, o impide, la emergencia de esta propiedad. Los principios o propiedades básicas que rigen a las estructuras que permiten la emergencia de la testeabilidad son, por supuesto, los principios de cohesión y acoplamiento. Si estas propiedades básicas no están presentes en la estructura del software entonces es muy difícil que emerja la testeabilidad.

Por eso propuse aumentar estratégicamente la atención en las propiedades básicas del nivel de pruebas de desarrollo, que es el nivel más básico. Si no se inicia por ahí, no sería viable llegar en un futuro a liberar capacidades independientes de negocio (“rebanadas de pastel”) de manera contrastable o comprobable.