La acción de escribir demanda ciertas habilidades por parte del escritor, destrezas del tipo intelectual. Por supuesto, dicha demanda varia con respecto al tipo de escritura, entre otros muchos factores.
Escribir textos para humanos, desde blogs hasta literatura, es desafiante si el propósito es hacer llegar un mensaje en forma clara y concisa, en la manera de lo posible.
Escribir textos técnicos para humanos y computadoras, también conocido como el acto de la programación artística de computadoras digitales, es también muy desafiante.
Basado en el contenido de las conversaciones típicas entre profesionales de TI, sospecho que muy pocas personas vivas hoy en día conocen en realidad qué conlleva efectivamente una comunicación común entre humanos y computadoras digitales a través de textos técnicos (también conocidos como código fuente).
¿Cuál es la idea del “QA”?
Si “QA” significa “Aseguramiento de la calidad”, entonces difícilmente debiéramos encontrar un miembro de proyecto que no tenga eso como su responsabilidad —asumiendo que los miembros en dicho proyecto adoptan valores, principios y prácticas orientadas a la calidad, como las de los métodos ágiles.
Si por “QA” se entiende “testing” (pruebas de validación y verificación, para propósitos de pruebas funcionales/integrales/aceptación) entonces pienso que la ya añeja práctica de contar con un grupo diferente de profesionales ejerciendo pruebas destructivas permanece siendo un buen consejo (si de encontrar defectos se trata, como lo describen Glenford J. Myers, Tom Badgett, Todd M. Thomas y Corey Sandler en su obra The Art of Software Testing).
Las pruebas unitarias en el contexto de la práctica del diseño basado en predicciones y asertos —test-driven design— es para los creadores del software, i.e. los programadores, (mentalidad constructiva); pruebas de validación y verificación, para propósitos de pruebas funcionales/integrales/aceptación, es para los testers (mentalidad destructiva). Por tanto, el rol de los testers no cambia mucho en el contexto de la adopción de métodos ágiles.
Más aún, asegurarse realmente de que la calidad este presente implica algo más grande que concebir al “QA” como un rol que tan sólo algunos miembros tienen en un proyecto de desarrollo de software.
Para su información, el resumen del ya famoso reporte The Standish Group CHAOS Report de este año lo pueden consultar en la siguiente página:
CHAOS Report Summary 2009
"These numbers represent a downtick in the success rates from the previous study, as well as a significant increase in the number of failures", says Jim Crear, Standish Group CIO, "They are low point in the last five study periods. This year's results represent the highest failure rate in over a decade"
Algunas veces la idea de toda una herramienta puede gravitar alrededor de un simple fragmento de código, que representa un mecanismo habilitador que da vida a una funcionalidad mucho mayor.
Es el caso de una herramienta sencilla que estoy escribiendo para uso personal. Se trata de una aplicación, basada sobre Windows Presentation Foundation, la cual me ayuda a subir archivos desde mi disco duro local hacia un número de sitios y carpetas en Windows Sharepoint y que sigue mis propios patrones de carga y publicación.
El todo de la herramienta gira alrededor de esta simple pieza de código:
Quiero compartir con ustedes una breve nota acerca de una idea. Por si les hace click y gustan agregarla a su toolbox profesional.
Cuando estimes o hagas una proyección de esfuerzo para crear algo —ya sea software o un documento con una especificación funcional) podrías considerar que existe una unidad mínima en la que estará expresada dicha estimación en tanto esfuerzo se refiere, y que dicha unidad es el episodio más básico en el cual es posible entrar en ese estado de flujo mental donde realmente puede suceder el trabajo intelectual.
Dicha unidad representa el episodio mínimo en el cual algo puede ser creado de manera ininterrumpida, ya sea este episodio una sesión de diseño y programación de software o una sesión para articular las ideas y crear un texto. Esta unidad mínima no incluye las interacciones con otros profesionales —colaboración necesaria para indagar y deliberar las particularidades de lo que se quiere crear— sino sólo el trabajo intelectual individual y por lo tanto dichas interacciones deberán medirse con otro tipo de unidades para una estimación integral.
Yo suelo nombrar a dicha unidad de trabajo intelectual: la sentada. Como diciendo: ¿En cuántas sentadas puedo lograr dar vida a este componente? o ¿puedo realmente completar el contenido de este documento en X sentadas?
La duración para una sentada dependerá de la persona, de la forma en que logra el ritmo mental que lo hace productivo. Para alguien puede ser el caso de que en realidad logre 2 sentadas por jornada diaria de trabajo, una por la mañana y una por la tarde. Para otros puede ser diferente. Una sentada a mediodía y otra por la noche. Aun para otros podría ser que logran tres sentadas por día en determinadas condiciones. Todo depende de la manera en que funciona cada uno haciendo trabajo intelectual.
Como se mencionó, el trabajo que no implica la creación de algo sino que es de una naturaleza más interactiva y de coordinación entre profesionales, se rige por diferentes patrones mentales y de comportamiento por lo que no aplica una unidad como la sentada.
La sentada tendrá más sentido cuando se le ve como unidad de trabajo productivo e individual, y partiendo de que en la cultura corporativa generalizada tenemos una muy establecida tradición de medir y evaluar el individualismo —toda la cosmovisión implicada—, entonces podría ser una técnica que puede ayudar a obtener mejores estimaciones.
Sin embargo, se ha detectado un patrón, un tanto ecléctico, en el trabajo intelectual para sentadas de diseño y programación de computadoras, el cual contiene una mezcla interesante entre trabajo intelectual ininterrumpido e interacción con otro profesional del mismo equipo para lograr una misma tarea. Uno de los nombres que ha recibido dicho patrón es Programación en pares (pair programming). Yo personalmente he lo llevado a cabo en ciertas ocasiones y la experiencia me ha sido muy positiva. Pero, para obtener lo mejor de esta otra técnica, implicaría repensar la cosmovisión tradicional individualista que nos rige, corporativamente hablando.
Algunas referencias:
Maker's Schedule, Manager's Schedule
Peopleware: Productive Projects and Teams (Second Edition) by Tom DeMarco, Timothy Lister
Pair Programming Illuminated by Laurie Williams
What a wonderful and fulfilling experience this of pair programming
El explorar y el descubrir que nacen de dudas simples —pensamientos del tipo ‘no estoy completamente seguro acerca de...’— es lo que hace al acto de diseñar software y programar computadoras tan emocionante para mí. Dudar desde la eficiencia o el balance de una decisión de diseño dada, hasta los beneficios netos y de largo plazo de creencias populares acerca del proceso de desarrollo de software en un contexto de negocio.
Basado en los resultados hasta ahora de mi agenda personal de investigación acerca del acto de programar computadoras, he corroborado que esta actividad puede ser reducida —considerando su esencia— a un puro acto de diseño. Consecuentemente, el mejoramiento o avance en la profesión de desarrollo de software va en el camino de mejorar las habilidades de diseño de los practicantes.
Diseñadores de software en el camino a convertirse en un profesional competente en software necesitará educación acerca del arte —por favor nótese que aquí el concepto de educación se está usando en su sentido más amplio y no sólo en la noción popular de escolarización— y acerca de metodologías de trabajo intelectual en lenguas, literatura, historia y filosofía. Por supuesto, como es el caso de la buena educación, esta es auto-infligida. En otras palabras, el entrenamiento se puede proveer pero la educación sólo puede ser escogida.
Entre el conjunto de destrezas en un diseñador de software, la habilidad de pensar críticamente resalta como una de las más importantes. El ejercicio del sentido crítico —en contraste con el sentido común— ha resultado ser de mucho beneficio para la tarea de diseño y directamente relacionado con los atributos de calidad del resultado, es decir, software ejecutable que entrega valor real de negocio.
El acto de concebir, diseñar y codificar software demanda ciertas conductas en quien lo ejecuta que han resultado ser muy similares a las que se observan tanto en artistas como en científicos.
Con base en las condiciones del proyecto de desarrollo típico, se puede identificar el tipo de proyecto que tenemos entre manos, y es una mezcla entre un proyecto de creatividad y de resolución de problemas. Definitivamente no es un proyecto de ejecución táctica, donde la receta para la solución se puede conocer al principio del esfuerzo y que la mera ejecución de tal receta nos produzca el resultado deseado.
Es prudente considerar un proceso de desarrollo acorde a la naturaleza del esfuerzo, uno que contenga —desde el principio— los mecanismos para aproximarse a la solución con base en los hallazgos y aprendizajes en el trayecto, uno que permita adaptarse a lo que se descubra como lo que sí se requiere y dejar de lado lo que resulte no tan adecuado, sin mayor costo.
Un ejemplo, en el renglón del diseño detallado, ocurre al adoptar un patrón de diseño para un ambiente de cómputo en particular: Know your design tools — The Singleton case.
La mente de Bjarne Stroustrup por medio del pensamiento y estilo de diseño del lenguaje de programación C++ (en específico: ISO C++) ha sido de una importancia fundamental para mi propio pensamiento y práctica de la programación. Sí, él es un filósofo de la programación de computadoras, un programador artístico (es decir, diestro, tal y como se explica en Artistic programming as theory formulation).
Principiantes a la programación de computadoras y experimentados por igual podrán obtener beneficios del libro: Programming: Principles and Practice Using C++, pues es presentada una buena variedad de conceptos y ejercicios, incluyendo perspectivas históricas en algunos temas. Además, los diseñadores de programas que cuenten con experiencia podrán encontrar muchas sugerencias pues el libro es el caso de cómo un experto explica y enseña a principiantes.
Como propuesta de lectura: en la sección 1.6 Ideals for programmers, se explica un proceso general de programación y se hace notar la importancia de cómo pruebas, análisis, diseño y programación están relacionadas en dicho proceso. Por tanto, tal vez para una mejor lectura, sugiero que el sexto párrafo, el cual dice:
“We can describe the process of developing a program as having four stages:”
sería más claro si se lee de esta manera:
“We can describe the process of developing a program as having four activities:”
Un individuo o un pequeño grupo de personas tienen una idea o un sistema de ideas que suenan prometedoras y de las cuales se obtienen resultados notables. Luego, esas mismas ideas son adoptadas por las masas pero entonces se observan resultados de un mucho menor nivel de trascendencia.
He observado este patrón en muchos disimiles contextos, desarrollo de software, negocios, religión, por nombrar algunos.
¿Por qué esto es así?
¿Será una fijación de percepción mía tal que —como lentes de color— me obligan a observar algo donde no lo hay? Quizás.
¿Cuál podría ser otra explicación o sistema de interpretación razonable para este patrón de conducta entre seres humanos?
Una posibilidad es que como parte de la causa raíz de la situación se encuentre un desproporcionado enfoque en el aspecto práctico de todas las cosas. La popular creencia en que las consecuencias prácticas son el único criterio por el cual debe ser juzgado el conocimiento, el significado y lo valioso.
Sospecho que un enfoque obsesivo, desproporcionado y exclusivo en los aspectos prácticos de un asunto conlleva la mayor parte de la culpa.
¿Cuántos de nosotros podríamos de hecho explicar la diferencia entre teoría y práctica, entre teoría e hipótesis, entre conocimiento confiable y creencia?
“Aquellos quien están enamorados de la práctica sin teoría son como un piloto quien navega sin un timón o brújula y nunca tiene alguna certidumbre dónde está yendo. Práctica debiera siempre estar basada sobre un sólido conocimiento teórico”
-Leonardo de Vinci (1452–1519)
“El problema con la gente no es que desconozcan pero que conozcan tantas cosas que no son ciertas”
-Josh Billings (1818–1885)
La idea de un sistema operativo en una computadora digital es servir como un administrador de los recursos de cómputo para que las aplicaciones no tengan que se programadas tomando en cuenta el funcionamiento específico de un modelo particular, por ejemplo, de disco duro. Así, una aplicación puede invocar una función del sistema operativo, digamos CreateFile, para conservar información en el disco duro sin importar los detalles de modelo y marca del mismo.
Un sistema operativo es un conjunto de componentes de software, algunos de los primeros sistemas operativos se mantenían activos en su totalidad en memoria ROM en todo tiempo. ¿Recuerdan a Commodore? Otros sistemas operativos eran leídos en su totalidad y puestos en memoria RAM cuando se prendía la computadora ¿Recuerdan Apple IIe o Franklin? Luego MS-DOS (disk operating system) combinó el esquema, leyendo parte del sistema operativo en RAM al encender la computadora y parte en disco (la cual se leí por demanda). La combinación agrega también la posibilidad de que los componentes del sistema operativo residan en la red a la cual está conectada la computadora.
Esa idea es también parte del concepto de servicio Web y nos permite hablar de un sistema operativo de red, en combinación con un sistema operativo en memoria RAM o en disco duro.
Un servicio Web de este tipo que hoy en día las aplicaciones pueden invocar es el servicio de autenticación usando Windows Live ID.
¿Qué se ha dicho que sea un rasgo de locura, de demencia o simple y sencillamente de total chifladura? “Repetir, vez tras vez, lo mismo y esperar que el resultado sea diferente”. Así me parece, como un serio trastorno, la conducta de muchas empresas privadas y públicas que, ignorando la historia de la actividad, se mantienen jugando ese pervertido juego del alcance y costo fijo para proyectos de desarrollo de software. ¿Qué tiene que pasar o cuánto dinero tiene que derrocharse para que entendamos que así no es como funciona esto?
Voy a dejar para después mis hallazgos de lo que creo hay en la raíz del problema. Por ahora, remito una recopilación de algunas ideas que han funcionado como parte de la solución al problema, es un artículo titulado “Mejores estimaciones” publicado en la revista Software Gurú del trimestre Agosto-Octubre 2008, página 52 (disponible gratuitamente en línea).
La Universidad de Washington, su facultad de Ciencias de la Computación e Ingeniería —a la manera de otras universidades tales como MIT y Stanford, con sus programas MIT OpenCourseWare y Stanford Engineering Everywhere— ofrece las videograbaciones de cursos y clases así como los materiales de sus cursos. Esto ha sido muy bienvenido por parte de aquellos interesados en el aprendizaje y la mejora continua.
Por ejemplo, el 21 de octubre de 2008, Joe Duffy de Microsoft ofreció una presentación acerca de Microsoft's Parallel Computing Platform: Applied Research in a Product Setting. La videograbación está libremente disponible.
La actitud mental para plantearse la realidad que ha ayudado a los humanos a explicar y predecir los fenómenos (hechos observables) de manera consistente y precisa, la mentalidad científica, es una de esas cosas que los profesionales de computadoras pueden adoptar para un mejor entendimiento de los fundamentos del desarrollo de software. Hay dos aspectos de alguna manera conflictivos en la actitud científica que la hacen tan atractiva precisamente por ese efecto de oposición.
Primero, esa impaciencia por hacer todo lo posible para traer a la mesa de trabajo las ideas previas y actuales de otros pensadores acerca del tema en cuestión, tal que el trabajo nuevo pueda estar basado sobre argumentos sólidos y conclusiones probadas. En contraste, ¿cuántos profesionales actuales del software dominan los conocimientos esenciales de los métodos estructurados para diseño? ¿Y de la primera, segunda y tercera generación de métodos para análisis y diseño orientado a objetos?
Segundo, en la esencia de una actitud científica está la constante disposición para refutar creencias actuales, para refutar nuestros propios puntos de vista, una inexorable tendencia por desconfiar de argumentos autosuficientes; esto es, poner nuestras conclusiones bajo las más severas y despiadadas condiciones posibles de prueba. ¿Por qué? Kenneth Boulding dijo: “El conocimiento se incrementa no por la coincidencia de imágenes mentales con el mundo real (que Hume apuntó es imposible), esto es, no por la percepción directa de la verdad, pero por una tendencia implacable hacia la percepción del error. Esto es tan cierto para el conocimiento vernáculo como lo es para la ciencia". En contraste, ¿cuán común es encontrar personas con una visión dogmática de su profesión en software? “Aquí sólo seguimos tal o cual moda”, “Ésta marca o moda en la única verdad posible”, etc.
La combinación de esas actitudes —racional y escéptica— es requisito para el progreso científico, esto es, para la acumulación de conocimiento confiable acerca de un tema dentro de la competencia de la ciencia (el mundo natural). Los filósofos de la ciencia han factorizado esas actitudes de la ciencia y las han puesto a disposición de otras disciplinas para que puedan también avanzar el conocimiento de sus campos de una manera rigurosa y confiable; por ejemplo, ciencias sociales como la sociología, economía, antropología (la cual incluye a la antropología física, arqueología, etnología, y la lingüística), ciencia política, y otras.
El mundo del software es un mundo de lo artificial, un mundo de estructuras lógicas gobernadas por un conjunto diferente de relaciones en notorio contraste con aquel del mundo físico y muy similar al del mundo de la lingüística, donde la relación entre el signo (símbolo), el significado (concepto) y el significante (imagen lingüística) es sujeto de significativos cambios entre un punto discreto en el tiempo (lingüística sincrónica) y su evolución (lingüística diacrónica). En tanto estemos interesados en conocer algo acerca del desarrollo de software entonces será mejor consolidar nuestras capacidades de pensamiento crítico incluyendo aquellas actitudes mentales mencionadas anteriormente.
He visto precisamente esas actitudes en practicantes de los llamados métodos ágiles para desarrollo de software; cabe hacer una distinción, los practicantes a los que me refiero no son aquellos que sólo usan las palabras de moda, sino aquellos que apuestan sus carreras en sus valores y principios profesionales; aquellos practicantes reflexivos quien respaldan sus creencias con sus conductas, aquellos que toman el planteamiento científico hacia la realidad como una herramienta, no como una religión. Estos individuos son perpetuos aprendices, científicos de facto en el campo del software. Para ellos, el nombre ágil sólo significa un punto de partida para un entendimiento cooperativo continuo, El término ágil significa tan sólo un signo para evocar un estilo conversacional, tal como el término adaptativo el cual, por cierto, fue el segundo nombre candidato de aquella reunión en Snowbird, Utah en Febrero 2001. En mi opinión, adaptativo refleja mejor el contraste con los planteamientos predictivos absolutistas y enfatiza la naturaleza siempre cambiante y autocrítica de los procesos modernos (o postmodernistas, desde una perspectiva filosófica) para desarrollo de software.
Los métodos adaptativos implican —adicionalmente— un modo dual de conducta en sus practicantes, así como el progreso de la ciencia requiere un esfuerzo dual para situaciones desatascadoras. Estos modos pueden ser llamados Evolucionario y Revolucionario, el primero se refiere de forma amplia a un estilo de pensamiento que busca la verdad profundamente en una sola dirección por medio de ciertas especializaciones y el segundo significa un estilo de pensamiento que extiende la perspectiva por medio de ciertas generalizaciones; los rasgos pueden ser como sigue:
|
Modo evolucionario |
Modo revolucionario |
| Artesanos |
Videntes |
| Jugadores en equipo |
Independientes |
| Normales. Evolucionistas. |
No comunes. Revolucionarios. |
Escaladores técnicos-ingenieros.
Escaladores de problemas. |
Viajeros. Exploradores. Filósofos. |
En el foro acerca de arquitectura en MSDN hay en curso una discusión acerca de la legitimidad del término arquitectura como parte del nombre de puesto o rol para profesionales en la industria del TI. Artesano podría ser un término más realista.
Además, el uso de la palabra “ingeniero” también tiene importantes implicaciones en lugares como Canadá, con un cierto número de controversias al respecto.
El arte no solo es Estética. La esencia del arte es habilidad, destreza, aptitud. Ingeniería se trata de la automatización de procesos bien conocidos y definidos, como el proceso de diseño de software aún no puede ser completamente automatizado, es pretencioso cualquier uso de la palabra “ingeniería” en el campo del desarrollo de software. Por eso, artesanía es un mejor término = arte (destreza) + ciencia (conocimiento confiable).
¿Cuál puede llegar a ser el error más común en la historia de la adopción del desarrollo iterativo e incremental?
Craig Larman propone una respuesta a tal pregunta en su libro Agile and Iterative Development: A Manager's Guide:
“Seguro, no aplicamos el proceso en cascada —todos sabemos que no funciona. Hemos adoptado <método iterativo X> y estamos en nuestro primer proyecto. Llevamos dos meses y tenemos casi terminado el análisis de casos de uso, y el plan y el calendario de lo que estaremos haciendo en cada iteración. Después de la revisión y aprobación del conjunto final de requerimientos y calendario de iteraciones, empezaremos a programar.
Este profundo malentendido, todavía sobreponiendo valores inspirados del proceso en cascada como hacer análisis y planeación únicamente al inicio (manufactura predecible) sobre métodos iterativos, es uno de los errores más comunes que cometen los adoptantes novatos de métodos ágiles e iterativos.”
Ciertamente, con base en el número de ocasiones y su frecuencia, encuentro a tal malentendido un buen candidato para ocupar dicho lugar en la historia de nuestra profesión.
