Saturday, October 14, 2017

Profesionalización

Quizá un camino que se aproxima más a la profesionalización, en el sentido de ejercer a cabalidad una ciencia o un arte, sea precisamente no buscar la profesionalización entendida como recorrer grados académicos y ascender estructuras jerárquicas, sino mantenerse como un devoto aficionado a la curiosidad propia y al aprendizaje; especialmente si ese aprendizaje es cooperativo, en conversación y en discusión con otros, sin ortodoxias académicas ensimismadas y desapegadas del resto del mundo.

Por fortuna yo no perdí tiempo estudiando filosofía en ninguna institución. Me hubiera sucedido lo que a Jonathon 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.

Saturday, October 07, 2017

Hermenéutica en software

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?

Procesos de aprendizaje

¿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: http://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/

Saturday, September 30, 2017

Análisis preliminar retrospectivo de decisiones de diseño

Líderes en la industria del desarrollo de software:

Por favor solicito unos minutos de su tiempo para hacer juntos un análisis preliminar retrospectivo de la decisión arquitectónica X en el proyecto Y. Pero aún más importante, para intentar juntos un análisis crítico retrospectivo de la madurez a la fecha del tipo de proceso arquitectónico que derivó en tal decisión y su correspondiente nivel de calidad. Dado el potencial derroche de tiempo y recursos de negocio asociado a tal decisión es necesario sopesar la posibilidad de tal decisión como defectuosa y, por tanto, sea necesario hacer ajustes en el proceso que la generó. Dado el nivel de impacto que un ejercicio de arquitectura tiene sobre un proyecto, y dados otros antecedentes de decisiones similares en otros proyectos pasados, sugiero repensar el proceso de arquitectura actual y repensar el tipo de dependencias entre grupos de trabajo que existe actualmente en dicho proceso.

Para lograr una cadena de liberaciones productivas de valor de negocio con calidad por arriba del promedio se requiere considerar procesos y dependencias de un tipo por encima del promedio.

El punto prospectivo principal que propongo discutir es el análisis, diseño, ejecución de pruebas y evaluación de la correspondiente evidencia para confirmar la calidad tanto del requerimiento de negocio —e.g., exactitud en reglas de negocio, oportunidad del caso de negocio, etc.— como de las decisiones en un proceso arquitectónico con una madurez quizá por arriba de los procesos imperantes no sólo de manera local, sino en la infanta industria de la creación de soluciones de negocio basadas en software.

Saludos y gracias.

I make mistakes, and want a safety net.Continuing lessons from my mistakes

Sunday, March 19, 2017

¿Qué es «Software craftsmanship»?

«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) http://manifesto.softwarecraftsmanship.org/

(2) http://agilemanifesto.org/

(3) http://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