Goce profesional

El 23 de diciembre de 2006, hace aprox. nueve años, publiqué la nota que ahora refiero. Esa nota recién llegó a mi memoria después de concluir hoy una intensa sesión de diseño y desarrollo de software. Una sesión por el simple y puro placer de diseñar y escribir código que hace funcionar a una computadora en la precisa pauta que le ordeno.

«It’s only writing code but I like it, ... I like it!!!» … «I like to write code.»

La nota es: You can have joy even if you do not have fun (lasting satisfaction).

Top coder

¿Alguien interesado en aprender a programar computadoras? A continuación refiero una estrategia sólida:

«Go to http://topcoder.com/tc and http://codeforces.com/. Participate in ALL competitions. Dedicate 4…6 hours a day practicing. Come up with a plan, like "10 easy problems per day, three mediums and one hard per week". Solve ALL the problems. Never let them hang. Develop a habit of going to bed with the feeling of accomplishment.

Ask on the forums if you are stuck; make it a habit to practice asking good questions as well.

Read other people's code. Learn from it relentlessly! ...» —Dima-Korolev

Repetición cíclica y aprendizaje

Una de las implicaciones de lo dicho en la nota El progreso de un aprendiz sería la idea de la repetición cíclica y su potencial relación con una idea general de aprendizaje.

¿De qué tipo de repetición cíclica estamos hablando aquí? Claro, no una que sea mecánica e irreflexiva, sino una que implique retroalimentación y la consecuente adaptación para el ciclo sucesivo.

Si por aprender también entendemos cambiar o mejorar en algo, entonces en cada ciclo uno podría identificarse algún delta de cambio o mejora en ese algo, por mínimo que fuese y cualquiera que fuese su signo (pues no toda repetición implica avance). En mi caso, una frecuente dificultad está en identificar ese delta pues suelo permanecer ciego de mi propio desempeño, o tiendo a ver sólo lo que me causa autocomplacencia, o estoy tan cerca de la situación que no alcanzo a ver el panorama y las deficiencias que se hacen aparentes sólo a distancia. Por eso, con la misma frecuencia, necesito la retroalimentación de otros.

Hay muchas corrientes y escuelas de pensamiento para la programación de computadoras, y, por fortuna, hay muchas donde la cooperación tiene un lugar predominante. Es decir, donde el diseño detallado (también conocido como «código fuente») es visto y revisado con frecuencia por más de un solo par de ojos. Por lo tanto, si alguno aquí busca ser practicante –como sigo intentando ser– de alguna de esas corrientes o escuelas cooperativas de programación, entonces podría, si gusta, compartir algún diseño detallado del que quiera retroalimentación. Así, los interesados podremos aprender juntos algo.

¿Alguien se anima?

Estudiar código de otros

La sola idea de aprender a programar no deja de interesarme. Quizá es por lo que solía decir Kristen Nygaard: «To program is to understand.»

Recién recordé años imberbes, y en perspectiva, reconozco la influencia que entonces tuvo tener en mis manos el clásico: Algorithms + Data Structures = Programs, de Niklaus Wirth (la edición Prentice-Hall de pasta dura de febrero del 76). Mirar el código en esas páginas, y sentir la urgencia de intentar esos programas en alguna computadora con el fin de entender lo que ocurría, fue emocionante.

Los básicos de la programación en ese libro siguen, para mí, igual de vigentes. Además, hay otros excelsos libros de introducción a la programación. Por fortuna puede uno acudir a maestros como Bjarne Stroustrup o Bertrand Meyer que, como Niklaus Wirth, son autores generosos. Por fortuna, podemos sopesar sus palabras que dirigen con lucidez a quienes buscamos aprender a programar; un par de ejemplos son las siguientes referencias. Además, reproduzco un párrafo del prefacio del maestro Meyer que al repasarlo me hizo recordar cuán importante es estudiar el código de otros.

Programming — Principles and Practice Using C++, por Bjarne Stroustrup.

TOUCH OF CLASS — Learning to Program Well with Objects and Contracts, por Bertrand Meyer.

«Because from day one of the course you will have the whole power of EiffelStudio at your fingertips, you will be able to skip many of the “baby” exercises that have traditionally been used to learn programming. The approach of this book is based on the observation that to learn a technique or a trade it is best to start by looking at the example of excellent work produced by professionals, and taking advantage of it by (in order) using that work, understanding its internal construction, extending it, improving it — and starting to build your own. This is the time-honored method of apprenticeship, which places newcomers under the guidance of experts.» —Bertrand Meyer

¿Por qué reflexionaría un programador de computadoras?

Jugar con una computadora ha sido para mí una constante fuente de gozo y diversión desde mi etapa adolescente. La idea de controlarla para que aparezca algo en la pantalla o para que haga diferentes cosas al pulsar diferentes teclas ha sido para mí puro pasatiempo. Aún recuerdo mi sorpresa al escuchar que jugar de esa manera podría ser un trabajo remunerado. Estaría dispuesto a pagar por la oportunidad de pasar mi tiempo divirtiéndome al explorar una computadora, cuán interesante ha sido que no he tenido que pagar sino que me pagan por jugar y divertirme al controlar computadoras para que hagan con exactitud lo que yo les dicto (algunas veces lo hacen). Cuánto más afortunado ha sido que hay mucho por leer y aprender sobre cómo controlarlas cada vez mejor. Ejercer control sobre un objeto complejo como una computadora es algo muy divertido para mí. El juego se llama: administrar la complejidad para lograr la ilusión de control y de simplicidad, entre más control y más simplicidad, más diversión.

Un aspecto de especial placer estético para mí ha sido el teclado. Me parece como una especie de clavicordio, el teclado me parece un extraordinario mecanismo sobre el cual puedo poner mis manos para intentar lograr algo artístico. Una computadora de hoy es una muy notable maquinaria.

Programar para mí no es un “trabajo” que me veo en la necesidad de hacer para obtener dinero. Para mí, programar computadoras es un juego y, por tanto, tiene que ser divertido y adecuado para muchas horas de ocio; de otra manera no tendría sentido para mí hacerlo. El “trabajo”, aquello obligado e indeseable, no ofrece espacio para reflexiones ociosas pues el trabajo es lo contrario al tiempo libre de una persona. Programar una computadora para mí es siempre una opción para mi tiempo libre, para mi ocio. Es ahí, en la recreación, donde se busca más gozo y más diversión, ahí cobran sentido las preguntas y la indagación por el conocimiento que ayude a avivar ese deleite. Pues el conocimiento intensifica el goce.

Por otro lado, otra condición para la reflexión es la tragedia. La desdicha puede impelernos preguntas que en otras condiciones no haríamos. Pasar muchas horas diarias haciendo algo de manera obligada e indeseable suena como un infortunio, como una tragedia. Ahí, al padecer el “trabajo”, también tienen sentido las preguntas y la indagación que ayuden a disminuir el tormento.

Regresar a los básicos implica formular preguntas muy básicas. Por ejemplo, ¿a qué nos referimos cuando decimos “programar una computadora electrónico-digital”? ¿En qué consiste hacer eso, aun si sólo queremos lograr algo “práctico”?

Reflexionaré más sobre esa pregunta más adelante. Aquí sólo citaré lo que el autor de The Art of Computer Programming ha escrito en varias publicaciones:

«Science is what we understand well enough to explain to a computer. Art is everything else we do.» —Donald E. Knuth

Lectoescritura y autoridad

Un libro de un autor como Bertrand Meyer no deja de llamar mi atención. Además, es un caso de estudio para mis meditaciones personales acerca del concepto de «autoridad». ¿Qué es «autoridad», cómo se logra, cuándo, quién, dónde, por qué y para qué? En parte, la búsqueda por distinguir quién es quién en creación de software es lo que guía mi interés por leer otro libro sobre disciplinas tanto artísticas como científicas en software. El prestigio y el crédito que justifican a una persona para pronunciarse de manera competente en una materia tan compleja y difícil como la creación de software se sostienen sobre la base de no poca pericia. Un dominio tanto de diversas teorías como de variedad de prácticas resulta necesario para cimentar autoridad en la ciencia y en el arte del desarrollo de software que retorna ganancias o entrega valor de negocio.

Por fortuna no todo programador opina que lo único valioso es el cortoplacismo desdeñoso de la investigación científica y del pensamiento crítico. Por fortuna hay quienes advierten que toda práctica tiene una teoría subyacente, y que una buena manera de mejorar la práctica es entender cada vez mejor la teoría que la sostiene o, dado el caso, reemplazarla por una teoría diferente. Por fortuna para la sociedad civil —que utiliza cada vez más algún tipo de software—, hay programadores que leen y escriben libros y disertaciones en búsqueda del desarrollo del pensamiento doctoral y de una práctica profesional cada vez más madura. De ahí la relevancia de cultivar la relación entre la lectoescritura y la destreza para diseñar software valioso. (Por eso el sinsentido de rechazar una propuesta por preferir un curso de creación literaria en lugar de tomar sólo exámenes de “certificación”.)

Historia como introspección

 

Mi recorrido por el diseño de programas en cómputo digital y teleprocesamiento de datos ha sido influenciado de manera particular por los enfoques de la comunidad C++ de autores, Bjarne Stroustrup en primer lugar. Esa influencia, además, incluye los enfoques propuestos por autores referidos por el mismo Bjarne Stroustrup como quienes han influido en su propia obra; e.g., Dennis M. Ritchie, Edsger Wybe Dijkstra, Kristen Nygaard, Niklaus Wirth, Ole-Johan Dahl, entre muchos otros (algunos de esos otros están listados en la sección «Masters» de un blog anterior en: Marco Dorantes' WebLog).

Una investigación amplia sobre la historia de las ideas en diseño de programas para computadoras digitales, o la ausencia de tal investigación, ayudaría a poner en perspectiva y a entender mejor los recurrentes problemas de calidad e insuficiencias de profesionalismo en la creación de soluciones de negocio basadas en software.

Si los problemas de calidad y las insuficiencias de profesionalismo siempre fuesen por completo explicadas al apuntar las deficiencias en los otros y no en uno mismo, entonces el individuo nunca tendría razón alguna para considerar que quizá su participación en los problemas es mucho más que una participación indirecta, o incluso para considerase como parte de la causa raíz de tales problemas. Un ejercicio histórico incluye identificar cómo otros han superado sus deficiencias, y eso puede servir para aplicar patrones similares a las deficiencias del presente. Si el individuo carece del hábito de ese ejercicio histórico, de esa perenne investigación, entonces se podría explicar por qué su inconciencia del nivel en que participa de las deficiencias de calidad y de profesionalismo a su alrededor.

La investigación de los problemas que nos aquejan suele ser parte del inicio de su solución. Las posibles soluciones no pueden siquiera iniciar su gestación histórica sin primero reconocer cuál es el problema, o si acaso existe un problema. Un análisis de la destreza profesional propia incluye identificar mis deficiencias y cómo llegaron ahí en primer lugar; es decir, incluye revisar el recorrido histórico personal con un escrutinio sistemático que las explique no como infortunios circunstanciales sino como parte de un diseño cultural explícito. En otras palabras, algunas de nuestras deficiencias pueden ser deficiencias del ambiente cultural en el que hemos estado inmersos y para reconocerlas con claridad será necesario aprender a desencajarse de ese ambiente y aprender a analizar procesos culturales con mayor amplitud. Si un individuo quiere participar de la gestación de soluciones a los problemas de esta industria, entonces puede considerar el hábito de la investigación histórica como un ejercicio de introspección.

Por supuesto, semejante proposición implica una especial dedicación, devoción y esmero por la profesión que uno ejerce y estima. Sin esa estima entonces se pueden explicar algunas reacciones típicas en esta nuestra sociedad del espectáculo ante mi proposición: “…eso está muy bien pero desgraciadamente no es práctico y resulta irrealizable dadas las presentes condiciones pues no podemos poner a todos a estudiar historia.” Reacciones como esa ponen a la desgracia como la raíz del asunto, como la excusa principal, por la cual el cambio, o el inicio del cambio, no es realizable. No dudo que haya desgracias que impidan exigir el cambio en algunos casos, pero cuando esas displicentes reacciones provienen de personas con los recursos necesarios y que están lejos de ser casos desgraciados entonces esas reacciones tan sólo son parte del problema y no de posibles soluciones.

Si para esfuerzos físicos, de pauta deportiva, de corto o mediano plazo vale la consigna: “¡Desafía tus límites!”, cuánto más debe valer la misma consigna para la profesión estimada y de pauta intelectual.

Profesionalismo y lenguaje

El profesionalismo está dentro de los temas que no dejan de interesarme, cuánto más hoy donde la aplicación del software está cada vez más presente en la sociedad. Recuerdo hace 25 años la primera vez que escuché la idea de que el software es una forma de tecnología. Fue curioso pensar que los programas y juegos que para entonces ya había hecho en Commodore-16, Apple IIe y PDP-11, y que hice con tanto gozo, fuesen una forma de tecnología. ¡A mí me parecía sólo un juego!, el cual planeaba seguir jugando.

Ahora el software y las computadoras están por todos lados, incluso en el humor, claro (imagen anexa).

Asimismo, apenas vamos ubicando, como civilización, qué es esto del cómputo digital y el teleprocesamiento de datos. Estamos en una fase donde proliferan los “brujos” y “chamanes” quienes, como antaño, usan la magia del lenguaje para encandilar a quien se deje. Recién leí la siguiente nota que menciona el caso del “archibabble” y la “talkitecture”: Should Software Architects Write Code?

En español, “archibabble” refiere a una especie de verborrea o guión de ventas cuyo soporte casi de manera exclusiva es el uso —o abuso— de presentaciones Powerpoint de gran atractivo visual, lo cual sirve básicamente para intentar impresionar a posibles compradores. La idea tiene una connotación peyorativa para los casos donde se abusa del lenguaje sin respaldarlo con software de calidad que entregue valor de negocio concreto y verificable en tiempo y forma.

El otro término, “talkitecture”, está muy relacionado con el anterior y se refiere a un exceso observable entre vendedores que se hacen pasar por ingenieros, y que padecen de graves niveles de analfabetismo técnico por lo que casi su único recurso es abusar del lenguaje para lograr vender proyectos de creación de soluciones de negocio basadas en software. Una parte de la explicación del fracaso de esos proyectos se debe a este tipo de abuso del lenguaje, el cual suele estar desapegado de los hechos materiales de la realidad en la creación de software de calidad.

Burocracia e ironía

¿Qué hay en común –además de las buenas intenciones– en los discursos, por ejemplo, del papa de la iglesia católica, del patriarca de la iglesia ortodoxa griega, del secretario general de la ONU, y de algunos otros prelados de ideologías corporativistas, públicas o privadas?

Parece ser una peculiaridad inevitable de algunas —quizá no pocas— corporaciones: la burocracia. Donde haya necesidad de regular la conducta humana por medio de normas dentro de un estricto orden racional por comando y control jerárquico, ahí la burocracia suele ser una alternativa muy frecuentada. Debe quedar claro: una burocracia sin excesos ni tropiezos indiscutibles tiene aspectos ventajosos. Sin embargo, lo inevitable de tal peculiaridad es sólo aparente pues hay otras alternativas para organizarse de manera efectiva y eficiente. Tanto es así que ahí, al aceptar dicha inevitabilidad en lugar de rechazarla en los hechos, está el exceso y el tropiezo por el cual la burocracia se ha ganado a pulso su mala fama: al aceptar la influencia excesiva de funcionarios en asuntos en los que son por completo analfabetas, al repetir acríticamente prácticas administrativas rígidas e ineficientes, y al acatar con vergonzosa genuflexión formalidades superfluas y –para decirlo con claridad– torpes.

Asimismo, los discursos que provienen de las cúpulas administrativas de esas corporaciones suelen contener expresiones que captan mi atención. Por ejemplo: «…What orthodoxy should I question?» en los párrafos finales de Satya Nadella en una publicación donde habla, entre otras cosas, sobre transformación individual y corporativa (Bold Ambition & Our Core). Desconozco si el individuo de marras tiene la capacidad para hacer una composición por escrito de ideas propias o cuenta con un grupo asignado que articula y redacta lo que debe decir en público y para el beneficio de las relaciones públicas de su corporación. Lo que capta mi atención de tal expresión, para empezar, es su posible ironía en dos sentidos: (1) con respecto a la educación de su audiencia, o (2) con respecto a la continuación de la cultura que dice querer transformar. Es decir, (1) si los aspectos nocivos de su burocracia interna ya son intolerables entonces tal expresión sería una burla fina y disimulada hacia quienes, para sobrevivir en su cultura corporativa, han sepultado por años toda posible habilidad para cuestionar y en su lugar han desarrollado año tras año una alta capacidad para acatar y someterse (en inglés: compliance). Por otro lado, (2) tal expresión podría ser una figura retórica para dar a entender lo contrario de lo que se dice y lo que en realidad busca es exigir de su audiencia un mayor grado de obediencia, docilidad y, en inglés, «compliance».

Arte, ciencia y programación

A partir de la programación de computadoras —o cualquier actividad humana sometida a examen crítico— se puede descubrir una riqueza cultural enorme, pero la aportación de la programación de computadoras a la indagación de la realidad tiene unos rasgos distintivos que la hacen muy atractiva para mí. Me refiero en particular al diálogo estético entre un cerebro basado en carbono (el cerebro humano) y un cerebro basado en silicio (el microprocesador digital). En el mismo eje temático de Donald E. Knuth, el diálogo que ocurre en una sesión de programación de computadoras sería una prodigiosa mezcla entre arte y ciencia:

«La ciencia es lo que entendemos suficientemente bien como para explicárselo a una computadora; el arte es todo lo demás.» —Donald Ervin Knuth, en su obra Things a Computer Scientist Rarely Talks About.

Análisis cultural

Por inverosímil que parezca a primera vista, los siguientes dos párrafos, y su tema general subyacente (pensamiento crítico), tienen una estrecha relación con mis otros proyectos personales de indagación. En particular los relacionados con las dimensiones de la creación de soluciones de negocio basadas en software: como un caso de estudio para el ejercicio de análisis cultural en la dimensión «Personas» (otras dimensiones son «Proceso», «Diseño/Arquitectura», «Tecnología»).

Por fortuna, algunos teólogos contemporáneos sí hacen un intento por divulgar su trabajo con claridad. Por fortuna, algunos de ellos no son del corte fanático que pretende apropiarse de toda la verdad y de toda la razón para el exclusivo uso de algún partido religioso, sino que hacen estudios en religión comparada. Por fortuna hay teólogos como William Willimon, en las ramas del protestantismo, o Karen Armstrong, o Albert Biesinger, en las ramas del catolicismo, que divulgan perspectivas distintas a las propias de la primera infancia de no pocos de nosotros adultos.

Como algunos saben, uno de mis proyectos personales de indagación es desarrollar una teoría teológica liberal, libertaria y libertina, así que no reparo en consultar fuentes diversas. Hace algunos días, en la librería de la Parroquia Emperatriz de América, de corte católico conservador, me topé con este libro de Albert Biesinger, teólogo católico egresado de Tubinga y Friburgo, Alemania. En este libro, entre otros similares, se puede constatar la riqueza de teologías basadas en interpretaciones no literalistas de textos antiguos veterotestamentarios y neotestamentarios.

La continuación de este blog...

He estado publicando notas en Español acerca de desarrollo de software en el siguiente blog*:  http://blogs.msdn.com/destreza/

Donde continúo reflexionando en la convergencia del ejercicio filosófico y la esencia en la actividad de crear programas para computadoras destinados a ser parte de la solución a problemas humanos.

*blog es una contracción de ‘web log’: un diario o bitácora pública como medio de expresión particular.

To test vs To proof vs To prove vs Proof vs Test

Pregunta: ¿Cuál es la traducción al español del verbo en inglés: to test?

Respuesta: Probar, examinar (averiguar si algo tiene o no cierta propiedad).

Pregunta: ¿Cuál es la traducción al español del verbo en inglés: to proof?

Respuesta: Probar. Hacer que algo sea resistente a cierta otra cosa.

Pregunta: ¿Cuál es la traducción al español del verbo en inglés: to prove?

Respuesta: Demostración. Establecer la validez de algo ya sea, por ejemplo, por explicación o por experimento.

Pregunta: ¿Cuál es la traducción al español del sustantivo: test?

Respuesta: Prueba, examen.

Pregunta: ¿Cuál es la traducción al español del sustantivo: proof?

Respuesta: Evidencia conclusiva: evidencia o argumento que sirve para establecer un hecho o la verdad de algo. Prueba de algo: una prueba o ensayo de algo para establecer si es verdad.

Popularmente, la actividad de probar en el ciclo de desarrollo de software –me parece– se refiere al verbo/sustantivo en inglés to test/test.

Pienso que para mejorar la calidad del software es necesario agregar lo relativo al verbo/sustantivo en inglés to prove/proof.

Existen técnicas para hacer justo eso, por ejemplo, los métodos formales. Pero se ha observado que la aplicabilidad de dichos métodos tiene ciertos requisitos que no se encuentran aún presentes en gran parte de los integrantes de la industria de desarrollo de software, e.g., grados académicos en matemáticas y la destreza para aplicar dichos conocimientos.

Por fortuna, también existen otras técnicas que están más al alcance de la mayoría, e.g, diseño conducido por aserciones (en inglés tiene un nombre algo engañoso: test-driven design).

¿Los arquitectos de software debieran programar?

Hubo un tiempo en la historia de esta industria en donde la palabra programador denotaba un gran respeto y apreciación, en particular tengo en mente la historia cuando el Profesor Edsger Wybe Dijkstra (pronunciado Edstar Dextra) inmigró a los Estados Unidos de Norteamérica y le preguntaron su profesión, dijo: programador.

Actualmente esa palabra —según creo— ya no tiene la misma connotación; en parte me parece debido a la economía de escalas y la inercia de las ideas de la revolución industrial de principios del siglo pasado. Ideas por las cuales, en un momento desafortunado, se asoció el estrato del personal poco educado y prescindible de las líneas de producción en las fábricas de manufactura al estrato de quienes con sus propias manos formulan el documento fuente del cual son creados los productos de software. Históricamente, ¿A quien se le habrá ocurrido por primera vez semejante correlación? Me propongo investigarlo, y no me asombrará si acaso se tratase de una mal interpretación como otras tantas que definen el pensamiento popular de nuestra industria actualmente (como por ejemplo el proceso de desarrollo en cascada cuyo supuesto inventor en realidad nunca ni siquiera mencionó la palabra cascada y de hecho como parte de sus conclusiones en su trabajo original dijo explícitamente que dicho proceso no debe ser ejecutado en fases secuenciales pues los resultados no serían adecuados).

Me parece actualmente —y ojala estuviera equivocado— que la palabra programador está asociada a la imagen de un chico joven y fuerte (para resistir las jornadas largas y lejos de casa), con poca experiencia, mucho entusiasmo, rápido para hablar y lento para escuchar. También en ocasiones, es el personaje que salva el día con todo tipo de suertes y trucos que solo él conoce y enmascara para conservar su poder, así como un Llanero Solitario de la programación.

Desde hace algunos años una nueva palabra ha tomado popularidad en nuestra industria, arquitecto de software, solo que en esta ocasión la cantidad de connotaciones que me he encontrado es significativamente mayor y el significado práctico me parece algo difuso. Pienso que la industria en su totalidad se beneficia cuando el significado se apega al del diccionario de la lengua española, arquitecto: persona que profesa o ejerce la arquitectura. Y a su vez, arquitectura: arte de proyectar y construir. En otras palabras, arquitecto de software: persona que profesa o ejerce el arte de proyectar y construir lógica computacional (software).

Una de las connotaciones que puedo observar asociadas al concepto de arquitecto de software es aquella derivada del tradicional arquitecto civil, cuyo significado según otro diccionario es: persona que planea edificios y supervisa su construcción. El tropezón aquí consiste en la suposición de que hacer software es similar a hacer edificios, lo cual ha resultado ser una suposición incorrecta pues —de hecho— formular lógica computacional es muy diferente de hacer edificios, y lo es en múltiples dimensiones, desde qué constituye el diseño del producto final hasta quién o qué obedece el plan trazado de construcción.

El terreno con frecuencia tiende a ser significativamente diferente al mapa que lo describe cuando estamos parados justo encima de dicho terreno, el punto de vista que se aprecia desde ese lugar suele revelar factores importantes que no se logran apreciar desde ningún otro punto de vista. La controversia de qué hace un arquitecto de software es natural pues hay muchas personas en nuestra industria que expresan sus opiniones únicamente basados en los mapas que disponen, pero nunca han estado parados en el terreno que pretenden prescribir. El dilema se presenta (como dice un muy querido amigo) "cuando la realidad impone sus reglas" y los que recorren el terreno simplemente observan que no es como dice el mapa ¿Qué hacer? Para cualquier propósito práctico, yo sugiero hacerle caso al terreno.

Propongo la siguiente definición que pienso es más apegada al terreno, arquitecto de software: persona que profesa o ejerce el arte de proyectar y formular lógica computacional en documentos técnicos ejecutables.

Lo más notable es el hecho de que frecuentemente practicantes profesionales como Grady Booch, y muchos otros autores y autoridades respetadas en la industria por el software que ellos mismos han diseñado y desarrollado, no solo imaginado, opinan lo mismo: Los arquitectos deben programar.

En otras palabras, I do subscribe to this point of view:

Software Architect's Role
"Implementation Expertise: Architect always implements. That basically means, "eat your own dog food". An architect must product designs that can be implementable software architecture. And she or he must be able to refactor when necessary. Thus, an architect needs to participate in implementing and unit-testing...." -
http://stal.blogspot.com/2006/03/software-architects-role.html

Referencias:
Should Architects Code?

Should Architects Code: Round 2

Architects Must Write Code

Testing Design

Saludos cordiales,
Marco

"Besides a mathematical inclination, an exceptionally good mastery of one's native tongue is the most vital asset of a competent programmer" -Edsger W. Dijkstra

Formulando software

Desarrollo de software se está convirtiendo en un término saturado, demasiados significados. Aunque tal vez no es exactamente lo que la industria necesita pero propongo un nuevo término con el que intento reflejar varios aspectos más particulares de la actividad de crear software; 'diseño de software' se puede considerar sinónimo de lo que intento comunicar con 'formular software'.

Podría haber escogido 'ingeniería de software' si no fuera otro término también saturado y por el momento pretencioso y exagerado.

De http://www.rae.es/ :

formular:
(De fórmula).
1. tr. Reducir a términos claros y precisos un mandato, una proposición, una denuncia, (... una lógica de conducta para una computadora.)

3. tr. Expresar, manifestar. (... comunicar la lógica de comportamiento del un programa, tanto entre seres humanos como entre humano-dispositivo de cómputo)

4. tr. Mat. Representar mediante signos matemáticos las relaciones entre las diferentes magnitudes de un enunciado. (representar en el fuente del programa, ya sea texto u otro medio, los elementos y las relaciones de composición de dicho programa)

5. tr. Quím. Representar mediante símbolos químicos la composición de una sustancia o de las sustancias que intervienen en una reacción. (Derivo la siguiente:)

6. tr. Comp. Representar mediante símbolos lógicos la composición de un programa o de los componentes que intervienen en una computación.