El arte de la programación

En este post explicaré mi opinión personal sobre la naturaleza del mundo del desarrollo de software. Como opinión personal que es, puede herir tu susceptibilidad o confirmar tus sospechas, dependiendo de tu propia opinión. Como dicen, quien avisa no es traidor.

La programación y la ingeniería de software

Estos dos términos, “programación” e “ingeniería de software”,  se usan como sinónimos y creo conveniente aclararlos antes de continuar.

Si buscamos en Internet por “programación”, encontraremos más de 72 millones de resultados. Si hacemos lo mismo con “ingeniería de software”, también hay más de 12 millones de resultados.  Es razonable pensar que la programación es un término más genérico que la ingeniería de software.

La “programación” según Wikipedia es “…el proceso de diseñar, codificar, depurar y mantener el código fuente de programas computacionales”. Creo que la descripción es muy concisa y clara.

La “ingeniería de software”, también según Wikipedia, es “…la aplicación de un enfoque sistemático, disciplinado y cuantificable al desarrollo, operación y mantenimiento de software, y el estudio de estos enfoques, es decir, la aplicación de la ingeniería al software”. Podemos simplificar la misma diciendo que es un enfoque “ingenieril” (en cuanto es sistemático, disciplinado y cuantificable) a la programación en sí.

Entonces, toda ingeniería de software es programación, pero no toda la programación es ingeniería.

El arte de programar

Y si hay programación que no sea ingeniería, ¿qué es entonces? Yo apuesto a que es un arte.

Vamos a ver como se define arte. En Wikipedia se define como “…cualquier actividad o producto realizado por el ser humano con una finalidad estética y también comunicativa, mediante la cual se expresan ideas, emociones o, en general, una visión del mundo, a través de diversos recursos…”. ¿Cabe nuestra idea de programación en la categoría del arte?

Mi opinión personal es que el producto de la programación, el código fuente, es susceptible de ser arte porque tiene una finalidad estética y comunicativa para expresar ideas y una visión del mundo. Existe la noción de código elegante, código sucinto, código que no necesita comentarios o código que es un galimatías.

Al final, programar es un acto de creación artística afín a la poesía, en mi particular teoría. En poesía el poeta está limitado por la rima, por la economía de palabras y por los efectos estilísticos y emocionales que quiere dejar en el poema. En la programación estamos limitados por el lenguaje de programación, el estilo del código que queremos marcar, los efectos secundarios en el hardware y por la economía de recursos. Sin embargo, mientras un poeta tiene un universo limitado de palabras del diccionario, los programadores no tenemos esta limitación ya que todo código se puede combinar para formar nuevas clases y métodos.

Seguro que a estas alturas del post os estáis preguntando que me he tomado para desayunar esta mañana. Tranquilos, quedaos un momento más y veréis que no estoy desvariando.

Ingeniería de software, software factories y otros seres imaginarios

Al principio he mencionado que la ingeniería de software es aplicar métodos “ingenieriles” a la programación, con el noble propósito de hacerla más predecible, más formal y más “industrial”. El problema que yo le veo a ese enfoque es que la programación no es totalmente reducible a la ingeniería. Me intentaré explicar.

La ingeniería mecánica, eléctrica o aeronáutica como disciplinas científicas aplican un proceso elaborado para resolver los problemas a los que se enfrentan. Para resolver un problema mecánico o eléctrico hay un conjunto finito de soluciones, más o menos conocidas, con sus ventajas e inconvenientes. Además, la “masa” con la que trabajan estas ingenierías (los materiales, la electricidad, los fluidos) es conocida, estudiada y no varía.

Vayamos ahora a la programación e intentémosle aplicar el enfoque de ingeniería. ¿Qué es nuestra “masa” con la que vamos a resolver los problemas que se nos plantean? A poco que miremos, veremos que es un horizonte casi infinito, ya que para un problema informático hay multitud de posibles soluciones, con sus ventajas y desventajas. La arcilla de los programas, el código fuente, es tan moldeable que tiene pocas reglas y límites sólidos. Sí, tenemos los límites del hardware, de la memoria y del tiempo de respuesta, pero estaremos de acuerdo que es una libertad de opciones de la que los ingenieros industriales o eléctricos podrían tener mucha envidia (no sé si la tienen).

No estoy diciendo que no podemos aplicar algunos preceptos de ingeniería a la programación. Por ejemplo, la archiconocida regla “DRY” (Don’t Repeat Yourself) es muy útil para simplificar el mantenimiento del código al eliminar código duplicado. Pero, a diferencia de la regla de Ohm que define como se comportan los circuitos eléctricos, la regla DRY es más bien una idea guía que no una ley absoluta. A veces es justificado repetir el código, porque obtenemos mejor rendimiento, por ejemplo.

Lejos de ser anecdótico, este ejemplo es el núcleo de mi exposición en este artículo. La flexibilidad del objeto y ámbito de la programación y la ausencia de límites físicos notables por su misma naturaleza impide que haya reglas escritas en piedra sobre la programación. Lo más a lo que podemos aspirar son guías orientativas.

Alguno de vosotros se estará preguntando si el hecho de tener patrones de diseño de software no es una muestra de que el enfoque de ingeniería es posible. Sí, los patrones son útiles, pero siguen siendo guías conceptuales y no recetas de aplicación mecánica. Si fuera así, no necesitaríamos programadores senior ni arquitectos, sino operarios entrenados a aplicar un algoritmo de creación de software. Y esto, niños y niñas, no es posible si queremos hacer bien la programación.

Un momento, dirá alguno de vosotros…¿y qué pasa con las cacareadas software factories de muchas multinacionales? ¿Y el off-shoring a la India? ¿No demuestran que la programación se puede mecanizar o industrializar?

Para mecanizar o industrializar un proceso, este tiene que ser repetible y estable. Si nuestro objetivo fuera hacer aplicaciones muy parecidas, con las diferencias bien identificadas y acotadas, podríamos hacer un proceso más o menos mecanizado de creación de las mismas. Se trataría de aplicar una guía de proceso, a rajatabla, y como resultado tendríamos aplicaciones milimétricamente precisas y garantizadas. Como los tornillos en una cinta transportadora de una fábrica.

¿Cuántas aplicaciones así habéis visto en vuestra vida? Puedo aventurarme a responder: cero. No existen. El mito de que podemos capturar toda la variabilidad del software al principio para poder aplicar un método (o, mejor dicho, “EL método”) es uno de los mitos más persistentes en el mundillo del software. Pero, aunque haya sido rebatido y expuesto tantas veces, se resiste a morir. Como COBOL.

Entonces, ¿por qué tenemos tantos procesos, metodologías, software factories, líneas de producción y demás artefactos “ingenieriles” en software? Mi sospecha es que lo hemos copiado por semejanza de otros campos, sin parar en pensar si aplica o no al nuestro. Ya hemos visto que en otros campos la materia prima es estable y con unos límites físicos conocidos. Nuestra materia prima es tan flexible y el abanico de respuestas tan extenso que gastar esfuerzos en intentar reducirla a un pequeñísimo conjunto de aplicación muy puntual es, cuanto menos, una farsa.

Ya puestos a copiar de alguien, creo que sería más apropiado copiarnos de los chefs de cocina o los directores de teatro, que combinan de manera creativa ingredientes variados para que el resultado final sea el deseado. No tienen una guía escrita en piedra sino que se adaptan a los cambios y a cada circunstancia.

El ser humano contra la máquina

Si el proceso de programación fuera predecible y mecanizable, podríamos (en teoría) construir un programa que pueda crear todos los programas posibles, preguntando los requerimientos al operario. Creo que no estoy solo en la convicción de que semejante automatización no puede cubrir, ni de lejos, todo el abanico de soluciones válidas y posibles en la construcción de software.

¿Cuál es la solución entonces? Yo creo que está en reforzar el papel de la persona, del programador o la programadora, sea arquitecto, programador junior, programadora senior o cualquier otro pretencioso título que esta persona tenga.

La persona puede decidir si una regla de software tiene sentido en un contexto determinado. La persona tiene el sentido estético y visceral de si un código es elegante o no, igual que cuando apreciamos de manera instintiva una obra de arte. Sí, tiene que tener conocimientos de programación, pero además tiene que tener una mente abierta, sentido crítico y mucha curiosidad. La persona podrá crear el software del siglo XXI, no la máquina.

El arte de la programación se puede describir en libros, pero como cualquier arte, se aprende practicando y analizando de manera crítica nuestros resultados. Por ello, uno de mis esfuerzos principales en SOGETI, como Team Lead, es crear un clima de trabajo en el que la práctica deliberada, la curiosidad, la experimentación y la maestría sean el caldo de cultivo de las personas que harán la programación dentro de SOGETI mejor cada día.

Averigua cómo SOGETI puede ayudarte en la puesta en marcha de proyectos IT.

Edin Kapić

SharePoint and O365 Architect – MVP | Soluciones Microsoft | SOGETI ESPAÑA