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

Wednesday, August 24, 2016

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.

Wednesday, July 20, 2016

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.

Sunday, June 19, 2016

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.

Monday, February 08, 2016

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.

Friday, January 08, 2016

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.»

Wednesday, October 07, 2015

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.