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.

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/

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

¿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

Testeabilidad

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.

Abonar a la deuda técnica

¿Qué es «deuda técnica», de dónde proviene y cómo se puede gobernar?

Si regresamos a los básicos de diseño de software, entonces podemos constatar que «deuda técnica» no es algo nuevo sino una idea de moda para referir lo mismo que autores como Meilir Page-Jones y Larry Constantine decían desde hace tres décadas sobre cohesión y acoplamiento y sobre el costo incremental inherente al nivel de desorden (entropía) en un sistema. Si, además, regresamos a los básicos de la teoría general de sistemas (pensamiento sistémico aplicado en cibernética), entonces podemos constatar que la entropía no se puede evitar, solo administrar.

La «deuda técnica», en general, es el nivel de desorden en un sistema. Proviene de los cabos suelos presentes desde la definición de un problema hasta los cabos sueltos en los detalles de implementación de una posible solución.

¿Cuáles son las implicaciones de intentar ignorar la «deuda técnica» o de no gobernarla adecuadamente?

Un efecto típico de «deuda técnica» no gobernada es, entre otros, la decisión de descontinuar un sistema pues su costo de evolución se hace insostenible o porque su capacidad para ajustarse a nuevos requerimientos es demasiado pobre y costosa. Para un negocio basado en software ese efecto puede ser devastador. Por ejemplo, para la compañía Netscape Communications tal efecto contribuyó al declive de su producto comercial Netscape Navigator y, a fin de cuentas, a su bancarrota.

¿Cómo gobernar la «deuda técnica» en un sistema?

No dejar cabos sueltos desde la definición de un problema hasta la implementación de una posible solución. Uno de los cabos sueltos más frecuentemente ignorados es la administración de dependencias en un diseño de software; es decir, abandonar tal diseño a la tendencia natural hacia el espagueti (entropía). El gobierno de una «deuda técnica» incluye aplicar pagos o abonos constantes: esfuerzo explícito para administrar las dependencias en cada cambio al diseño en todos los niveles de abstracción involucrados en dicho cambio. Si no se abona a la deuda, ésta tan sólo crecerá.

Por supuesto, hacer un cambio a un diseño demanda contar con pruebas manuales y automatizadas pertinentes que ayuden a identificar el nivel de propagación de las consecuencias de dicho cambio.

En este contexto sugiero evaluar la siguiente aportación que recién publiqué. Se trata de un componente para administrar dependencias como medio para gobernar la deuda técnica en diseños de software que utilicen .NET Framework:

http://www.nuget.org/packages/TypeClassMapper/

Está basado en una idea básica de extensibilidad existente en Windows desde C++/COM/COM+ y también en .NET Framework. Dicho mecanismo sirve para concretar un patrón de diseño llamado Inversión de Dependencias o Inversión de control (Dependency Inversion Principle, DIP). El cual permite desacoplar por completo una interfaz de sus posibles implementaciones y ser enlazadas por separado en runtime por medio de configuración.

En años recientes muchos han empaquetado dicho principio en varias librerías. Algunas han cobrado alguna popularidad. Nunca he usado dichas librerías pues suelen agregar mucha funcionalidad que no necesito y que sólo las hace innecesariamente grandes; además de aumentar la complejidad del software que las usa.

Su documentación y ejemplos de uso están en el Project Site correspondiente.

Toda valoración crítica, reporte de defectos, solicitudes de funcionalidad, o de cambios, y contribuciones abiertas son bienvenidas.

Razón vs experiencia vs intuiciones

Al entrevistar candidatos para posiciones dentro de mi grupo profesional en arquitectura y diseño de software busco un rasgo determinante: sus contribuciones a proyectos de código abierto (public open source projects). El estilo de colaboración, patrones y técnicas de diseño e integración a ese tipo de proyectos, para mí, es evidencia clave para saber a quién estoy entrevistando, más allá de palabras impresas en su currículum o mucho más allá de número de “certificaciones”.

Yo dejo muy poco a mi mera intuición pues no me ha resultado muy confiable. No se me da eso de percibir de manera inmediata la realidad detrás de las apariencias. Para lograr un juicio profesional yo necesito primero averiguar los hechos de la experiencia y también examinar los argumentos de un caso. De hecho, al entrevistar candidatos acostumbro pedirles que realicemos una sesión conjunta de diseño de software directamente en una computadora y con algún compilador, por más o menos 30 minutos. Juntos colaborando sobre un problema de diseño y una aproximación a una posible solución. Es como una sesión «pair programming».

Sí, la mera intuición juega algún papel, pero explícitamente evito que sea determinante. Mi razón principal está en la rendición de cuentas pues hay mucho en juego: la calidad del software y su impacto en la satisfacción de clientes y usuarios de un proyecto de desarrollo no es algo que, de ser posible, deje en manos de una corazonada —por supuesto, en el caso de «mera intuición» como eso, como un presentimiento. Hay, claro, otro tipo de intuición: la intuición profesional, pero esa es muy distinta de una corazonada o presentimiento. La intuición profesional suele estar basada en muchos casos variados de ejercicio tanto racional como experimental.

Precisamente eso, una mezcla particular entre el uso del raciocinio y de la experimentación, es lo que intento identificar durante la sesión cooperativa de diseño y programación que hago durante la entrevista. Dejo en claro que no intento medir cuánto sabe el candidato, sino su disposición para el trabajo intelectual cooperativo. Crear software no trivial es un esfuerzo intelectual con mejores resultados –en mi experiencia– si se hace cooperativamente. Por ejemplo, el candidato necesita no sólo disposición para aprender de otros, sino también para enseñarles efectivamente; de ahí que si aprendí un par de cosas del candidato durante esa sesión inicial, entonces definitivamente llamó mi atención.

Entonces, digamos que lo que me dice a la fecha mi intuición profesional es que, para mejores resultados en un proyecto de desarrollo, tengo la responsabilidad de seleccionar a los candidatos con un perfil científico básico: con un uso adecuado tanto de la razón como de la experiencia, y de una capacidad mínima para poner en tela de duda —para cuestionar— sus ideas previas sobre un asunto (y así dejar espacio para aprender algo nuevo).

¿Cómo ven? Todo esto está relacionado con un intento por tomar mayor conciencia sobre profesionalismo entre quienes practicamos el desarrollo de software como profesión.

Más al respecto en: (1) Why a Reflective Developer Program?, (2) El Programa para el Desarrollador Reflexivo - ¿de qué va?

Cualquier retroalimentación es bienvenida.

Una práctica reflexiva

En relación a una iniciativa que traigo entre manos (Reflective Developer Program), me dirijo a ustedes como profesionales del desarrollo de software. Es decir, asumo que se ven a sí mismos como eso: como profesionales del desarrollo de software, o esa representa para ustedes una opción importante en su carrera profesional de largo plazo.

¿De qué va el Reflective Developer Program? En una frase: es una invitación para regresar a los básicos del profesionalismo aplicado a creación de soluciones de negocio basadas en software. En la página Why a Reflective Developer Program? hago un intento por resumir algunas ideas embrionarias del programa. Lo relevante es fomentar el tipo de diálogo implicado: conversaciones entre los interesados en mejorar la actitud reflexiva en el ejercicio de nuestra profesión.

Hay muchas preguntas que orientan un programa profesional como el Reflective Developer Program. Una de ellas es: ¿cómo es un paradigma de profesionalismo maduro en creación de soluciones de negocio basadas en software?

Unas acciones clave del programa ante tal tipo de preguntas son: investigar sobre nuestra profesión y desarrollar una conciencia autocrítica del estado de profesionalismo personal. Una fuente para la investigación son las carreras de practicantes maduros en nuestra industria. Algunos de ellos aparecen listados en la sección Masters y en la sección Thought Leaders del siguiente blog: http://blogs.msdn.com/marcod/.

Recomiendo examinar cualquiera de los libros de tales autores, así como sus publicaciones en línea. He seguido la pista de algunos de ellos desde hace dos décadas, en particular a los que considero los autores de la tercera generación de métodos sistemáticos de análisis y diseño de software. Entre los cuales está Robert C. Martin. A continuación algunos ejemplos de sus publicaciones recientes en línea, su sitio en Amazon y, además, una liga a los que considero principios interesantes para lograr diseño de software estable y de una calidad por arriba del promedio. Esos principios son algunos de los que me orientan para evaluar diseños, y son los que busco aplicar en proyectos importantes.

Esto es una invitación para dialogar sobre desarrollo de software como profesión, para aprender mutuamente de nuestro propio ejercicio profesional, y para reflexionar y debatir sobre estilos de aprendizaje y mejora profesional en general. Cualquier ocasión propicia en nuestro día a día puede ser oportunidad para discutir estos temas desde la sintonía propuesta; es decir, desde la reflexión profesional y la conciencia crítica.

A Little Architecture.

Stabilization Phases.

Robert C. Martin books.

Principios de diseño de software.

Especificar e implementar

Un diseñador profesional de software, hoy 2016, que tenga miras de tomar más conciencia del estado del arte en su profesión, requiere estar al tanto de los adelantos a la fecha tanto de la teoría como de la práctica en creación de soluciones de negocio basadas en software. Esto significa, también, estar familiarizado con el estado de la discusión profesional al respecto de preguntas fundamentales de la naturaleza de su actividad; por ejemplo, ¿cómo está relacionada la acción para especificar con la acción para implementar?

Las preguntas fundamentales suelen no tener respuesta definitiva, sino sólo suelen tener historia. La reflexión al respecto del ejemplo anterior encuentra su material de estudio en la historia de la profesión; por ejemplo, en la publicación de William Swartout y Robert Balzer, julio de 1982, ‘On the inevitable intertwining of specification and implementation’:

«Contrary to recent claims that specification should be completed before implementation begins, this paper presents two arguments that the two processes must be intertwined.»

Responsabilidad y libertad profesional

Responsabilidad: Capacidad del sujeto para reconocer, aceptar y responder ante las consecuencias de un hecho realizado libremente. Cargo u obligación moral o profesional que resulta para alguien del posible error en un asunto determinado.

Los creadores de software deben ser responsables de lo que hacen. Esto es muy relevante en nuestra civilización pues para funcionar ésta se basa cada vez más en software. ¿Alguien está interesado en mejorar la creación de software? Entonces deberá considerar que los creadores de software requieren más libertad para entonces demandarles más responsabilidad. La libertad a la que me refiero aquí es aquella que un profesional tiene para hacer mejor su trabajo. Por ejemplo, si un programador profesional está en un ambiente laboral que le deja muy poco tiempo para auto-cultivarse, entonces tendría menos libertad profesional y no sería congruente demandarle mayor responsabilidad en ese ambiente. Otro ejemplo, si una organización limita la libertad de un programador profesional para acercarse a las experiencias cotidianas de sus clientes y usuarios al usar el software en cuestión, entonces está limitando el tipo de libertad que podría aumentar la responsabilidad de dicho programador. Una manera en que una organización podría limitar la libertad aquí ejemplificada es creando estructuras organizacionales que aíslan al programador y le impiden reconocer, aceptar y responder ante las consecuencias de su trabajo. Otra manera en que una organización limita la libertad profesional aquí referida es asignando demasiados proyectos simultáneos a los creadores de software, de tal manera que tienen menos tiempo para reconocer, aceptar y responder ante las consecuencias de lo que han hecho.

Es propio del humano cometer errores, y no se puede hacer nada para lograr perfección absoluta. Pero aquí no hablo de eso; es decir, no hablo de lo que está fuera de nuestro alcance, no hablo de lo que no está en nuestras manos y no se puede hacer nada al respecto. Por otro lado, aquí hablo de lo que sí está en nuestro alcance para reconocer, aceptar y responder mejor ante lo que hacemos como profesionales en creación de software.

«Design and programming are human activities; forget that and all is lost.» —Bjarne Stroustrup. The C++ Programming Language. pp. 693.

Aclaraciones pertinentes

Aclaraciones pertinentes

Un abuso de moda en desarrollo de software es la palabra “ágil”, así como lo fue “orientado a objetos” hace una par de décadas, o “estructurado”, hace más de treinta años. El abuso está en que esas palabras refieren a muchas cosas pero no a una mayor destreza para crear software de calidad.

Un uso adecuado –es decir, más consciente– de esas palabras implica, para empezar, el esfuerzo de leer autores que históricamente hayan hecho investigación sobre problemas relevantes relacionados con esas palabras. Este esfuerzo inicial requiere el nivel más básico de lectura de compresión, nada más. Este primer paso no demanda habilidades superiores de lectura.

Por fortuna, sí hay practicantes que estamos dispuestos a no sólo hacer el esfuerzo de ese paso inicial, sino que también buscamos mejorar nuestra habilidad para leer. Nuestra lista de lectura incluye autores como los listados en la sección «Masters» y «Thought Leaders» del siguiente blog: http://blogs.msdn.com/marcod/

El punto importante es tener la mira en mejorar el nivel de destreza personal y ser cada vez más competentes para crear soluciones de negocio basadas en software. Además, esa mejor destreza incluye colocarse uno mismo en mejor posición para tener mejores conversaciones con no-practicantes; es decir, con personas que por alguna razón están involucradas en creación de software pero que no tienen competencia ni compromiso directo con tal proceso creativo. En tales conversaciones habría muchas oportunidades para hacer aclaraciones pertinentes para darle un mejor significado al uso de palabras como “ágil”, o como “arquitectura”.

En la siguiente nota de Arlo Belshee se menciona una conversación en donde el practicante podría hacer algunas de esas aclaraciones pertinentes: We are not fucking competent.

¿Cuál es el algoritmo del éxito?

En SG #48, algunos puntos para discutir sobre el ejercicio metodológico en creación de software: ¿Cuál es el algoritmo del éxito?

Scrum Nexus

Recién Ken Schwaber comentó sobre Nexus. al parecer, el uso y demanda de Scrum ha aumentado de unos años para acá. Quizá Scrum es ahora el más popular entre los métodos ágiles de aquella época en que se publicó el Manifiesto Ágil. Una de las preguntas frecuentes hacia los creadores de Scrum, según observo en algunas comunidades de desarrollo, es: ¿cómo aplicamos Scrum en proyectos cada vez más grandes y con múltiples grupos de desarrollo?, i.e., ¿cómo escalar Scrum?

Suele ocurrir algo con lo popular, sin embargo. Gerald M. Weinberg lo describe en su Ley de la mermelada de frambuesa: entre más se esparce un poco de mermelada en la superficie de un pan, menos mermelada le toca a cada parte de ese pan. Es decir, entre más popular se hace Scrum, tanto su teoría como su práctica se diluyen cada vez más hasta que se convierte en algo casi irreconciliable con Scrum. Por ejemplo, desde las primeras etapas del desarrollo del esquema conceptual de Scrum, por la década de los noventas, se consideró al control empírico como guía durante el ciclo de vida del software; en contraste, en donde Scrum se ha hecho popular hoy suele pasarse por alto ese simple hecho de la historia de lo que se dice practicar.

Mi sugerencia –también aquí– es regresar a los básicos de Scrum, e intentar no caer en la tentación de “escalarlo”. Por ejemplo, regresar a los básicos de Scrum significa preguntar e indagar: ¿qué es controlar empíricamente?

De cualquier forma, el regreso a los básicos incluye analizar y comprender las perspectivas de su evolución. Por eso tiene mucho sentido indagar sobre Nexus, y sobre otros esfuerzos y análisis sobre las condiciones en que “escalar” métodos ágiles no ha terminado en desastre. Un par de ejemplos de esos análisis es este y este.

La miseria de la univocidad

En desarrollo de software, como profesión, hay, por supuesto, diversidad de perspectivas sobre qué es calidad y cómo lograrla en la realidad. También aquí, como en política o en religión, tal diversidad se distribuye a lo largo de una amplia gama de posiciones agrupadas en múltiples dimensiones de la creación de software; por ejemplo, la dimensión de la administración de un proyecto o un conjunto de proyectos (también llamado portafolio de proyectos), o la dimensión financiera de inversión y su retorno, o la dimensión de operación sustentable y niveles de servicio, o la dimensión de arquitectura y diseño a lo largo de múltiples niveles de abstracción, etc.

En administración de proyectos hay desde el extremo fanático del estricto comando y control jerárquico del «taylorismo posindustrial», hasta el otro extremo fanático en el jardín hippie del subjetivismo radical donde el «cowboy coding» reina supremo.

La creación de software puede ser una fascinante aventura intelectual para el profesional que se interesa por la historia de su profesión. Se requiere investigar el contexto de una posición histórica y sus razones de fondo para luego contrastarla con el contexto y razones de otra posición. Esta clase de reflexión histórica es para mí esa aventura intelectual y profesional. Pero se requiere mantener la curiosidad y las ganas de entender qué es crear software como profesión. Además, se requiere valorar la otredad, la heterodoxia y la inclusión de perspectivas diferentes a la propia. De otro modo –es decir, desde la ortodoxia–, se corre el riesgo de interpretar toda otra perspectiva desde la premisa de que es inferior en todos los casos.

Un enfoque inclusivo permite un desarrollo profesional amplio y diverso, un desarrollo que agrega cada vez más herramientas de pensamiento y práctica. Así, la cantidad de opciones a disposición de ese practicante reflexivo a la hora de tomar decisiones de diseño, o de arquitectura, o de administración, no queda restringida a las opciones que ofrece la miseria de la univocidad.

Patrones y anti-patrones

Patrones y anti-patrones en creación de soluciones de negocio basadas en software

Si un proyecto, como una totalidad, se contempla como un sistema humano, un sistema organizacional, entonces puede tomarse por sí mismo como un objeto de análisis, diseño y liberación productiva. Sistemólogos, sistémicos y sistemistas investigan numerosos proyectos desde esa perspectiva y suelen reportar sus hallazgos en términos de patrones y anti-patrones. En ocasiones haré mención de tales conceptos, por lo que se hace necesario resumirlos e ilustrarlos de manera concisa con la intención de aclararlos.

Problema: no pocos clientes se quejan de que su saldo bancario es incorrecto.

Contexto: el problema ocurre cada vez que se realizan dos operaciones al mismo tiempo sobre el mismo registro electrónico de saldo de un cliente; por ejemplo, si el cliente dispone $700 en efectivo usando un cajero electrónico al mismo tiempo en que la misma cuenta bancaria recibe un depósito en ventanilla de $200, el saldo resultante refleja sólo una de las operaciones, el saldo parece ignorar que la otra operación haya ocurrido y, por tanto, es un saldo incorrecto. Además, el saldo final es inconsistente entre diferentes casos de quejas de parte de los clientes; es decir, continuando con el ejemplo, si el saldo antes de las operaciones fuese de $1000, en algunos casos el saldo final resulta en $300 y en otros casos en $1200 cuando el saldo final correcto es $500. La causa del problema está en que al calcular el saldo final de manera simultánea por dos procesos diferentes, cada proceso partió del mismo saldo inicial y registró su propio resultado sin provisión alguna de que tal saldo inicial fue modificado en el transcurso de la operación.

Solución: modificar los procesos de modificación de saldo para que apliquen el concepto de «transacción», el cual permite que operaciones simultáneas sobre el saldo mantengan la consistencia buscada.

Lo anterior es un ejemplo del concepto de «patrón de diseño»; es decir, una regularidad en la relación tripartida entre un problema, su contexto y una solución satisfactoria y estable para dicho problema. Los patrones suelen clasificarse en categorías; por ejemplo, patrones de diseño, de análisis, de proceso, organizacionales, etc. A continuación un ejemplo de un «anti-patrón organizacional», este otro concepto suele ser la contrapartida de un patrón; es decir, la práctica de lograr una solución pero insatisfactoria o inestable.

Problema: no pocos clientes se quejan de que su saldo bancario es incorrecto.

Contexto: mismo contexto anterior.

Solución: retirar la capacidad de los clientes en general para consultar su saldo bancario de manera electrónica y crear un servicio bancario personal para tal consulta, pero sólo para los clientes que contraten tal servicio especial y paguen las comisiones adicionales debidas al esfuerzo administrativo de calcular un saldo consistente de manera manual.

La solución del anti-patrón anterior es exagerada y superficial, quizá irreal, pero sirve para aclarar un rasgo que distingue a los anti-patrones: el exceso en que se incurre debido al desconocimiento o aplicación incorrecta de otros conceptos clave; en este caso el concepto de «transacción».

Programar como profesión empresarial

¿Por qué hablar de profesionalismo?

Cuando la profesión principal de un negocio hace uso de otras profesiones a veces la interacción no resulta tan clara y ocurren desencuentros, malentendidos o expectativas insatisfechas. En la búsqueda por la claridad en la interacción entre profesiones en ocasiones puede ser útil una sana controversia que promueva valoraciones críticas balanceadas y justas. La siguiente conclusión preliminar tiene la intención de promover la discusión racional sobre el profesionalismo en desarrollo de software en un contexto de negocio.

Riesgos de negocio y rendición de cuentas

Cada vez más empresas suelen tener al menos un departamento o una área de «Tecnologías de información (TI)» pues han determinado que necesitan aplicar la computación electrónica para los fines de su negocio. Si la administración de un negocio sigue la regla básica de mantenerse en su giro comercial y no desenfocarse en esfuerzos dispersos, entonces una pregunta prudente que no debe olvidarse es: ¿representa mi área de TI sólo un centro de costos o es un activo que permite mejores resultados empresariales?

Algunas áreas de TI también son responsables de desarrollar software aplicativo; es decir, el software concreto que procesa la información empresarial con las reglas del negocio en particular. Para crear dicho software la empresa decidirá entre contratar servicios externos o agregar programadores a su nómina, o un esquema mixto.

La decisión de agregar programadores a la nómina implica que además de conocer el giro principal del negocio ahora se requiere conocimiento sobre cómo administrar la actividad de programación de computadoras. Cuánto conocimiento adicional se requiere está en función de cuánta responsabilidad tendrían los programadores internos. Si el esquema de tal decisión es mixto y deja la mayor parte de la responsabilidad de crear el software empresarial en manos de un grupo externo de profesionales, entonces la empresa requiere menos conocimiento que si la mayor parte de dicha responsabilidad quedase en las manos del grupo interno.

Un esquema atinado tiende a designar la mayor parte de la responsabilidad a quien demuestra la mayor parte del profesionalismo; o sea, que cada quien se dedique a lo que mejor sabe hacer y en lo que mejor pueda rendir cuentas. Lo cual coincide con una regla básica de empresas exitosas: conoce tu oficio.

Si un esquema designa la mayor parte de la responsabilidad al grupo interno, entonces se requiere de una estrategia para el crecimiento profesional y para la retención del talento interno; de otra manera la cantidad de riesgo de negocio aumenta debido a un conocimiento subdesarrollado en la materia. Programar computadoras en el contexto de un negocio puede llamarse «creación de soluciones de negocio basadas en software» y profesar tal actividad, como cualquier otra profesión, requiere desarrollo constante de conocimientos. En otras palabras, un negocio sin profesión pone sus resultados en mayor riesgo.

Datos, información y conocimiento

Aquí hay otro riesgo que debe ser debidamente administrado: el primer tropiezo que hay que evitar es confundir conocimiento con información o con datos. Los datos pueden transmitirse de persona a persona e incluso transmitirse de manera electrónica. La información es una interpretación subjetiva de dichos datos. Por otro lado, el conocimiento humano no es algo que pueda transmitirse sino sólo puede ocurrir al desarrollarse de manera personal; es decir, el conocimiento ocurre en la persona que logra un entendimiento de algún aspecto de la realidad objetiva, la cual es intersubjetiva y verificable con independencia de cómo nos gustaría o quisiéremos que fuese esa realidad.

El conocimiento humano es algo que requiere elaboración y desarrollo paulatino (como el caso de software complejo) y no algo que pueda generarse de manera instantánea (aunque hay casos de software simple que sí es generable instantáneamente por medio de software más complejo).

Arquitectura empresarial

Por supuesto, una empresa de mayor tamaño requiere la coordinación de un mayor número de profesiones. De ahí la necesidad de algo llamado ‘arquitectura empresarial’ o la acción de diseñar una empresa en su contexto de mercado, sus profesiones y sus procesos, sus modelos financieros, etc.

Si una empresa apuesta en serio por contar con su propia capacidad empresarial para crear software, entonces deberá también apostar por la profesionalización interna de tal actividad. Es decir, por el desarrollo interno de profesionales de la creación de soluciones de negocio basadas en software y no sólo contar con departamentos de IT que justifiquen el argumento de Nicholas Carr en su artículo «IT Doesn't Matter» de mayo 2003 en Harvard Business Review.

Profesionalismo en desarrollo de software

Hasta donde alcanzo a ver a la fecha, y por mucho que sea la sorpresa inicial, aún no está claro qué tipo de profesión es la creación de software; pero si revisamos su incipiente historia de apenas 60-70 años entonces la sorpresa disminuye. No es una disciplina de ingeniería, y no pocos autores demuestran porqué nunca lo será, pero sí requiere la constante aplicación de conceptos ya bien definidos a situaciones concretas. No es del todo una ciencia que entendamos ya por completo y con la que se pueda controlar y predecir con exactitud toda causa y efecto relacionado, pero sí requiere mucha abstracción y conlleva patrones de pensamiento lógico-matemático. No es del todo un arte que sólo pocos iniciados puedan realizar sino que hoy en día está al alcance de muchos. Crear soluciones de negocio basadas en software es quizá aún una artesanía en evolución en forma, por ahora, de un oficio cuasi-gremial.

Sin embargo, una empresa necesita aprender a identificar a los practicantes de ese gremio artesanal, ya sea para reclutarlos o para referirlos durante el desarrollo de su propio talento interno. Un rasgo a identificar es la coherencia entre lo que piensan y lo que hacen; lo importante es no sólo decirse profesional de la programación de computadoras, sino demostrarlo con la liberación y la evolución sostenida de software de calidad que resuelva problemas a un negocio o le habilite nuevas oportunidades.

Una empresa puede identificar a quienes están en el giro de la creación de soluciones de negocio basadas en software por la calidad del software que son capaces de entregar. Son profesionales cuyo giro de negocio depende de crear confianza en la calidad de su software y suelen carecer de una red corporativa de emergencia que les cobije en caso de mala calidad. Tales practicantes, por medio del ejemplo, suelen contribuir semillas de lo que llevaría a esta artesanía a ser una profesión conocida y respetable —no parece que esta industria esté en ese punto aún; por ejemplo, es muy difícil todavía relacionar lo que hace un programador con lo que hace un neurocirujano, a pesar de que ambos manipulan cerebros con sus propias manos, ya sea un cerebro basado en silicio o uno basado en carbono, respectivamente.

La dimensión de la complejidad que conlleva la creación sostenible de soluciones de negocio basadas en software es tal que le exige respeto a quien la contempla y le invita a la humildad. Por lo que otro rasgo de un practicante es que cultive activamente su propio nivel de conciencia sobre tal complejidad y en aprender cómo otros la abordan y la administran de manera sostenible. Por tanto, nadie que afirme altivamente dominar por completo esta profesión es realmente un practicante del gremio aludido aquí; por supuesto, puedo estar equivocado.

Además del cultivo personal, un practicante se enfoca también en el cultivo de otros practicantes a su alrededor a través de valores como el diálogo, la comunicación y la cooperación sobre aspectos de la profesión compartida. Cada voz cuenta y es preferible hablar cara a cara con regularidad en lugar de sólo a través de documentos. Someter las ideas y el trabajo propios a la crítica de otros y escucharles con atención es un hábito del profesional practicante; así como realimentar lo más atinadamente posible a los demás.

El desarrollo del profesionalismo implica muchas cosas que giran alrededor de los efectos y acciones derivadas del verbo «profesar», entre lo cual, en este caso, está la intersección entre ingeniería, ciencia y arte.

Referentes

Los practicantes del gremio aquí aludido suelen investigar con esmero y aprender de las obras de diversos autores profesionales en la materia. Algunos de esos autores a lo largo de la historia de esta profesión han sido: Edsger W. Dijkstra, Kristen Nygaard, Niklaus Wirth, Ole-Johan Dahl, Dennis M. Ritchie, Donald E. Knuth, C.A.R. Hoare, Bjarne Stroustrup, Larry L. Constantine, Alan Kay, Bertrand Meyer, Adele Goldberg, Frederick P. Brooks, Jr., David L. Parnas, Tom DeMarco, Gerald M. Weinberg, Tom Gilb, Barry Boehm, Winston W. Royce, Caper Jones, Jim Gray, David Harel, Barbara Liskov, Rebecca Wirfs-Brock, Peter Coad, Sally Shlaer, Stephen Mellor, Andrew Koenig, Ivar Jacobson, Grady Booch, Ward Cunningham, Robert C. Martin, Erich Gamma, Jeff Sutherland, Kent Beck, Dave Thomas, Ken Schwaber, Andrew Hunt, Steve McConnell, Alistair Cockburn, Jim Highsmith, etc.

Conclusión preliminar

En conclusión, si al arquitectar una empresa se contempla contar con la capacidad de crear soluciones de negocio basadas en software, entonces también se necesita profesionalizar tal función de manera interna. La profesión de crear soluciones de negocio basadas en software, como parte de una empresa o como negocio por sí mismo, suele emerger con pauta propia y sus practicantes pueden identificarse por la calidad de su software, por su auto-cultivo y por su trabajo cooperativo.

Depuración del proceso de desarrollo

Si me exijo rendir cuentas de mi profesión y de mi rol en esta industria del software, y partiendo de una conciencia mínima de lo que es ejercer la arquitectura de sistemas, entonces también me obligo a mí mismo a intentar aportar más ante ese reto que todos compartimos: ¿cómo mejorar la calidad de los sistemas y el nivel de servicio hacia clientes y usuarios?

Estoy de acuerdo en que suele ser inútil imponer o exigir la transformación de los demás si a la par no exijo los cambios pertinentes de parte propia. Pero si tomamos la pauta de «no imponer» como principio profesional, entonces por consistencia habría que resolver la cuestión de por qué los clientes y usuarios tienen que padecer la imposición de un nivel de calidad aplicativa por debajo de sus expectativas.

Algunas personas cambiamos en la medida en que tomamos cuenta de que somos parte del problema. Esa conciencia, en ocasiones, llega a través del diálogo. Pero hasta para dialogar de manera efectiva se requiere preparación y no ignorar los básicos; por ejemplo, prestar atención a las razones del otro. En ese sentido, como sugerencia y como tan sólo una parte de la estrategia ante el reto de la calidad, si podemos indagar y enfrentar las razones de fondo en el proceso de desarrollo que ha producido el presente nivel de calidad, entonces sería como hacer “debug” a ese proceso. Tal “process debugging” representa una práctica aceptable en la profesión; ejemplos: Software Engineering Classics: Software Project Survival Guide / Debugging the Development Process / Dynamics of Software Development.

Otro estilo de vida

Sí, ya sé, muchos ya ejecutan sus proyectos de desarrollo de software de tal manera que cada día salen del trabajo después de ocho productivas horas de muy gratificante esfuerzo intelectual, y que viven plenamente otros aspectos de su vida personal en el tiempo que antes pasaban en onerosas y estériles actividades con poco o nulo progreso. Además, liberan software de calidad en la pauta acordada y se aproximan mucho más, y más rápido, al valor de negocio que en realidad se requiere. Todo eso ya lo sé, pero mi punto al tocar el tema es que aún muchos proyectos están atrapados en esquemas anticuados y, por tanto, hay muchos clientes y usuarios que aún sufren las consecuencias de enfrentarse a software creado como si fuese un producto de la manufactura de inicios del siglo pasado.

Programar es entender

Título alternativo: Programar computadoras es más, mucho más, que sólo escribir código.

En torno al aprendizaje de la programación y su relación con las oportunidades de negocio basado en software me llega a la mente la frase «If you build it, they will come.», la cual aplica para algunos casos en que la sola presencia de una posibilidad técnica provoca el brote de una necesidad que de pronto requiere satisfacción; Whatsapp sería un caso, saber programar jugó un papel, por supuesto, pero con “programar” no digo sólo escribir el código sino, además, entender los detalles de «push notifications» a cabalidad; lo cual jugó un papel clave en el modelo aplicativo y, por tanto, en el modelo de negocio, sus alcances y sus limitantes. Sabemos que la frase no es regla sino es más un golpe de suerte, pues hay muchos casos de lo contrario; por ejemplo, ¿recuerdan el dispositivo Newton, de Apple?, ¿NeXTStep?, ¿Oslo, de Don Box?

En torno a las oportunidades de negocio y su relación con el profesionalismo comentaré de manera sucinta que en ocasiones el valor a largo plazo en los negocios suele estar bien cimentado y apuntalado sobre un muy alto nivel de calidad en lo desarrollado. Semejante expectativa de calidad está relacionada a una no menor expectativa en calidad profesional. Si la calidad en software es igual a la calidad profesional entonces los programadores están entre quienes ejercen altos estándares en conocimiento científico sobre cómputo digital y también en ética profesional; por supuesto, estándares que no incluyen incurrir en concesiones por la sola razón de intereses económicos parciales (“mi cuota, mis commitments, mi compliance, mis bonos,…, y que los clientes sirvan a mis intereses en primer lugar.”) a costa de arriesgar la calidad y el prestigio profesional. Los negocios pueden mantenerse, además, con buen profesionalismo, como lo alude Bjarne Stroustrup en una plática reciente cuando muestra un tipo de código en C++ y menciona que ese tipo de código ha sostenido la vida profesional y económica de no pocos en esta industria.

Un mejor profesionalismo no debe significar más burocracia; como, por ejemplo, es el patético caso real de una organización que anuncia con gran pavoneo que su nivel de ingeniería de software ha mejorado pues ahora su métrica de documentos cumplidos para lograr una certificación ya llegó a 6,000 documentos. Un mejor profesionalismo implica mejorar tanto teoría como práctica. Si se cojea de una de ellas el resultado es sólo caminar en círculos, y no la mejora en calidad profesional.

Un cierto anti-intelectualismo imperante en algunos ambientes en nuestra industria provoca un rechazo inmediato ante la palabra ‘teoría’, pero pienso que sólo es una trampa del lenguaje; es decir, usan la palabra ‘teoría’ cuando en realidad quieren decir otra cosa. Pienso que con frecuencia quieren decir «falta de progreso» en un proyecto donde sólo hay «exceso de actividad». Entonces la trampa está en confundir cantidad de actividad con cantidad de progreso.

Por el contrario, cuando digo mejorar la práctica teórica me refiero a repensar una determinada estructura conceptual con el objetivo de mejorarla o reemplazarla por una más adecuada. Es decir, trabajar la teoría es entender mejor lo que está pasando detrás de las acciones, lo cual es aquello que en buena medida las gobierna. En otras palabras, no es suficiente hacer algo, sino también es indispensable entender mejor por qué se hace. Para ilustrar lo que intento decir me apoyaré en lo que explica el Dr. Raj Shah con su ejemplo de la multiplicación: Why is Math Different Now.