Programación, ¿arte o ciencia?

Antes de empezar, matizar que nada de lo que se indique se refiere a diseños de interfaces de usuario o similares. Parece lógico pensar que eso sí es un arte en la medida en que un buen (o mal) diseño visual es una excepcional vía para trasmitir emociones al usuario. La cuestión tampoco se refiere a si el producto resultado de dicha programación es arte o no. Por ejemplo, también parece claro que un juego tiene más de arte -de transmisión de emociones- que de ciencia aunque de esto último también tenga muchísimo.

La cuestión se refiere a si el hecho en sí mismo de programar es un arte o una ciencia. Si se basa más en la virtud o habilidad para hacer algo (arte) o en conocimientos obtenidos durante observación y razonamiento sistemático del que se obtienen principios generales (ciencia).

Un problema, muchas aproximaciones

Tal vez parte del problema respecto a si la programación es arte o ciencia se deba a que fijado un problema hay muchas posibles aproximaciones. Es posible hacer una cantidad infinita de variantes del mismo programa -todas ellas cumplirán el objetivo fijado- pero unas estarán basadas en algoritmos más o menos eficientes y lógicos y otras estarán basadas en vericuetos y caminos escabrosos.

El desconocimiento de técnicas de programación y algoritmos no impide por tanto realizar trabajos de programación. Ese es el primer problema dado que cuanto más cercano esté el programa a un algoritmo bien definido más fácil será su sistematización y, por tanto, más cerca estará de la ciencia.

Durante las fases de aprendizaje de un programador, desde que es novato hasta que se convierte en experto (Peter Norvig, que algo de esto sabe, fija este proceso en no menos de diez años), se producen importantes cambios en su forma de analizar y abordar un problema.

Cuando es novato tiende a utilizar todos los recursos del lenguaje de programación, sin quizá demasiado rigor científico. Demanda constantemente más información y puede empezar a trabajar sin comprender complemente el problema. A medida que va acercándose a la maestría alinea más el momento de comprender el problema en su completitud con al momento de empezar a programar. Utiliza un subconjunto de las capacidades del lenguaje de programación y sistematiza el proceso de forma continua. Es decir, tiene una metodología y en ese sentido, cabe pensar que la metodología es lo que acerca la programación a la ciencia.

Sin embargo, cuando el programador se convierte en experto se vanagloria de seguir el manual de buenas prácticas. Y el manual de buenas prácticas está bien, muy bien, pero no es una ley o principio general (que es la base de la ciencia). Es eso, un manual de buenas prácticas. A nadie se le ocurriría que un ingeniero de caminos siguiera un manual de buenas prácticas para calcular la resistencia de materiales en el diseño de un puente. Sigue leyes matemáticas no buenas prácticas y quizá por ello la imagen de la derecha tenga su punto de humor dado que, lógicamente, no es habitual ni previsible.

Las pruebas

Las pruebas, sin duda, permiten encontrar fallos en los programas, en unas ocasiones por una mala programación y en otras por un mal diseño previo. Sin embargo, las baterías de pruebas no son la solución sino la consecuencia del problema. La realización de pruebas a posteriori se puede usar para demostrar la presencia de errores en un programa, pero nunca para demostrar su ausencia (Dijkstra). Lógicamente, también los ingenieros de ramas más tradicionales hacen pruebas a posteriori para verificar si lo construido es correcto pero la gran diferencia es que sus pruebas están basadas en fundamentos matemáticos. Es decir, verifican si la construcción se ha hecho con arreglo a las leyes generales pero no dudan de tales leyes.

Sin embargo, en el caso de la programación esas leyes generales no existen salvo que desde el inicio se defina una metodología clara de las pruebas que se llevarán a cabo durante la fase de test. La existencia misma de esa metodología hará que los programadores eviten los problemas en origen.

Fuente: SecurityFocus

Esta idea se muestra de forma nítida en la programación segura. Por ejemplo, hasta 2005 Microsoft era la referencia mundial más clara de programación insegura. Sus bibliotecas de código estaban plagadas de fallos que podían ser explotados -y de hecho lo eran- en ataques de buffer overflow y otros fallos. Tanto es así, que Microsoft era asociada con la mala calidad (desde el punto de vista de seguridad) de sus productos. Algunos, como Internet Explorer, tenían fallos clamorosos y antológicos día sí y día también.

Todo fue fijar una metodología clara para los programadores e invertir en formación sobre programación segura y el número de fallos descendió de forma drástica hasta valores considerados como normales (similares a los de sus competidores). Nuevamente, parece que la existencia de una metodología (leyes) es definitiva para pasar de arte a ciencia.

Terminando

La confianza en la calidad del software es fundamental y lo será mucho más cada día que pase. Hay errores mediáticos como el del error de división en el Pentium, el efecto 2000 o Ariane 5 (lista completa de los 20 errores de software más famosos), y hay otros muchos que día a día pasan desapercibidos pero complican sobre manera la vida a los usuarios.

Etimológicamente, arte en griego se escribe τέχνη, raíz de la que también derivan palabras como tecnología o técnica. De hecho, en la Edad Media las universidades se dedicaban a enseñar las siete artes liberales, esto es, gramática, retórica, lógica, aritmética, geometría, música y astronomía. Y la programación informática depende de, al menos, tres de esas artes -hoy en día claramente ciencias-, a saber, gramática, lógica y aritmética.

Desde entonces, a lo largo de muchos siglos, se viene demostrando que actividades que hoy en día son claramente consideradas como ciencia empezaron siendo arte. Quizá un ejemplo muy claro de ello sea la medicina, que pasó de chamanes a científicos. Fue la forma sistemática y razonada de abordar los problemas lo que terminó por fijar la categoría de esas actividades como ciencia.

Tal vez, lo que nos falta es más metodología, más CMMI, más Scrum,... En definitiva, más rigor científico. O tal vez sea posible que algunos elementos de la programación sean intrínsecos de la mente humana al no poder ser modelados o automatizados y por tanto estén siempre en el ámbito del arte. Ahí dejo la cuestión.

www.tonsofit.com

¿Qué significa ser 2.0?

De tanto usarlo hasta nos hemos acostumbrado pero, ¿qué quiere decir exactamente que una cosa es 2.0?

El término, como es de esperar, nace en el mundo TI para representar un nuevo paradigma en la Web pasando de lo estático a lo dinámico, de la unidireccionalidad a la bidireccionalidad.

Permite pasar de "el dueño de la Web es quien genera los contenidos" a "el dueño y los usuarios colaboran creando conjuntamente los contenidos".

Básicamente, la Web 2.0 trata de la compartición de la información, la interoperabilidad, el diseño centrado en el usuario y la colaboración. Realmente, trata de más cosas pero, por simplificar, con las ideas básicas puede ser suficiente. Hasta ahí nada nuevo bajo el cielo porque se trata de información accesible en Wikipedia.


Nuevo enfoque

Sin embargo, aprovechando el tirón mediático de la tecnología otros muchos se han subido al carro de esto de ser 2.0. Ya no sorprende oír hablar de cosas tan dispares como Empresa 2.0, Personas 2.0, Liderazgo 2.0, Educación 2.0, Política 2.0, Coaching 2.0, Directivo 2.0, Banda Ancha 2.0, Televisión 2.0, Comunicación 2.0, Padres 2.0 o incluso Sexo 2.0.

En general, hay muy poco de la génesis de Web 2.0 en todas estas -supuestamente nuevas- formas de entender la vida. Por poner solo un ejemplo, se entiende por empresa 2.0 a aquellas compañías que utilizan las redes sociales para difundir sus mensajes comerciales, crear comunidades de interés, buscar la complicidad de sus clientes, identificar nuevos productos y mercados, mejorar las técnicas de segmentación,... En general, utilizan el software social mejorar su interacción con sus clientes y potenciales clientes.

A nivel interno utilizan las herramientas de gestión del conocimiento y el software social para crear comunidades de expertos entre los empleados, gestionar el conocimiento distribuido o fomentar el sentimiento de pertenencia.

Pero, ¿no es esto lo mismo que siempre han hecho las empresas de éxito? ¿Qué hay de nuevo en todo eso? ¿En qué momento, con los medios que en cada momento tenían a su alcance, han dejado las empresas de buscar la intimidad con sus stakeholders? Realmente, lo único que ha pasado es que se han sustituido las tarjetas de visita por los perfiles de Linkedin, y los archivos en papel por gestores documentales distribuidos, que no es poco, pero tampoco es para hablar de revolución.

Donde sí se produce un avance real es en el control de la gestión. Los clientes y empleados de las empresas 2.0 pueden hacer uso de los mismos medios en los que la empresa se publicita para demostrar con hechos que lo que predica no es coherente con lo que hace.

En general, en las redes sociales el control está distribuido por lo que ambos, empresa y clientes/empleados, tienen acceso por igual a la información. Ahí entra en juego la responsabilidad social de la compañía e incluso su ética. Eso sí es un avance.

Esto podría explicar conceptos como Empresa 2.0, Directivo 2.0 y hasta Política 2.0 pero la cosa se vuelve más compleja cuando se trata de aplicar el razonamiento a Educación 2.0, Televisión 2.0 y no digamos ya a Sexo 2.0. A ver si alguien se siente con fuerzas de argumentarlo.


www.tonsofit.com

El lado humano de la tecnología

Desde hace semanas mantengo una discrepancia -muy divertida, por cierto- con un compañero respecto a si debemos cambiar una determinada tecnología en base a que la que propone es líder del mercado.

Y la verdad es que basándose únicamente en la cuota de mercado y en los informes de los analistas no debería haber ninguna duda; pero la hay.

Mi opinión, y de ahí el título, es que la vertiente humana de la tecnología es mucho más importante que la tecnología en sí misma. Me baso en dos razonamientos; a ver si soy capaz de argumentarlos como es debido.

• Primer argumento. Un técnico con gran experiencia en una tecnología determinada es infinitamente mejor que una tecnología superior pero de la que no se tiene experiencia. Siempre he creído y sigo creyendo que la mejor tecnología del mundo puede volverse lenta y perezosa en manos de personal sin la capacitación adecuada. Y al revés, que unos buenos técnicos son capaces de sacar chispas a una infraestructura de segunda oleada tecnológica. Todo ello, lógicamente, dentro de unos límites razonables, que tampoco es cuestión de pedir que se hagan maravillas con una tecnología de hace diez años. Pero a igualdad de tecnologías (cuando ambas sean de la misma hornada), la diferencia de rendimiento, estabilidad y seguridad (resiliencia, vaya) entre unas y otras depende más de las personas que de la propia tecnología.

• Segundo argumento. Los problemas son principalmente generados por las personas no por las máquinas. La empírica dice que más del 60% de los problemas del Data Center están generados por errores y maniobras indebidas del personal de TI, fundamentalmente por decisiones erróneas en momentos de crisis. Más aún, el ratio de fallo de un componente hardware o software considerado como seguro es de 10-6 ó menor mientras que el ratio de error de una persona está en torno a 10-4.

Fuente: General Human-Error Probability Data in Various Operating Conditions.
Carnegie Mellon University

El cuadro anterior de Carnegie Mellon University es aplicable a personal de TI pero también a un arquitecto, un mecanógrafo o un bombero. Luego, las personas son el componente más vulnerable del sistema (más que las máquinas y el software) y, por tanto, tener técnicos muy bien formados y motivados es clave para un Data Center estable.

Para cerrar más el ámbito de la decisión, indicar que ambas tecnologías, la existente y la propuesta, cumplen razonablemente igual de bien los requisitos de la instalación dado que las dos están entre las tres primeras referencias del mercado. Y aunque la tecnología propuesta es más cara (que para eso es líder de mercado) por razones coyunturales ambas tendrían un coste idéntico incluso incluyendo la adquisición de licencias. El cambio, caso de producirse, implicaría alteraciones a todos los niveles en las aplicaciones, desde la programación (cambios menores comparativamente) a la gestión y operación del CPD (profundos).

Con todos esos datos sobre la mesa, ¿cuál sería la decisión más acertada? Y sobre todo, ¿cuál es el grado de acuerdo con los dos razonamientos sobre los que apoyo la argumentación?

www.tonsofit.com