Este es un proyecto cancelado que no recibe actualizaciones. No obstante, puedes acceder a su archivo como referencia.

Versión Cero

Programar no es sólo hacer matemáticas

Sergio Montoro

Cada cierto tiempo se oyen voces críticas sobre la falta de rigor con la que trabajan la mayoría de los programadores. La falta de métodos formales de verificación y benchmarking produce muchos programas lentos y nada fiables. Pero ¿es la programación sólo una extensión de las matemáticas por otros medios?

por Sergio Montoro Ten, 30 enero 08

El pasado 9 de diciembre Robert Scoble tuvo la en apariencia inocente ocurrencia de preguntar en su blog porqué el software de gestión no puede ser igual de sexy que el de consumo Más de cien comentarios y acusaciones de que no entiende el software empresarial como la de Michael Krigsman pusieron de manifiesto que con la pregunta Scoble tocó hueso.

En defensa de Robert salió el reputado Nicholas Carr, diciendo que es Krigsman quien no entiende nada de software y que creando una falsa dicotomía entre el software de consumo y el software de gestión lo único que se consigue es dar a los fabricante de éste último la excusa perfecta para seguir creando aplicaciones difíciles y desagradables.

El flame war continuó con otra andanda de Krigsman argumentando que Carr vive en un mundo de fantasía donde es posible emplear tiempo en dotar a las aplicaciones empresariales de pijadas totalmente innecesarias antes que atender a los requisitos funcionales básicos, las prioridades del negocio, el soporte de aplicaciones legacy y las limitaciones tecnológicas de la infraestructura.

Pero el clímax de esta historia lo he alcanzado leyendo una referencia en el blog de Agustín González-Quel al artículo Where Are the Software Engineers of Tomorrow? de Robert B.K. Dewar y Edmond Schonberg. En el cual los papás de ADA despotrican abiertamente contra el uso de Java para fines pedagógicos en las universidades, argumentando que el uso de Java es nocivo porque en vez de incentivar la reducción de la complejidad formal de procesos a un pequeño conjunto de operaciones primitivas, lo que Java fomenta es la resolución de problemas cual fontanero en ferretería tirando de todo lo que pilla en lo cajones a modo de frameworks y librerías que acaban convirtiendo al estudiante en un ignorante total del coste computacional de lo que está haciendo y de nociones imprescindibles para la programación como son los punteros.

Es verdad que entre los programadores más jóvenes hay una excesiva tendencia a abusar de las librerías. Cogen unos mágicos tags de Java y convierten una JSP que antaño era fácilmente legible y rápida en un amasijo de abreviaturas crípticas que tiran contra lentísimos servlets que hay que recompilar cada vez que quieres tocar algo. O se pillan Castor (o lo que sea) y unas DTDs y te dejan varios cientos de clases basura pregeneradas para leer un archivo XML de 10 líneas. Es decir, a veces matan moscas a cañonazos simplemente porque lo que tienen a mano para combatir insectos es un cañón.

Pero no es menos cierto que Java ha supuesto un gran salto cualitativo hacia adelante en la programación. Quien ha programado con punteros se acuerda de que en los 80 y 90 estábamos hartos de ellos y de las pérdidas de memoria que siempre acaban provocando. Y fue por eso que acabamos quitándolos en los lenguajes modernos. Hubo un tiempo en el que se cuestionaba la eficiencia y la viabilidad de usar recolectores de basura como el de la máquina virtual de Java, cuya utilidad y eficacia ahora ya nadie se atreve a poner en duda. Cuando no teníamos esas librerías ballena de Java, nos dedicábamos a escribirlas ¿Alguien se acuerda de ACE o de Rogue Wave para C++?

Por supuesto que hay muchas cosas muy mejorables en Java. Pero para mi Java ha sido un avance y no un retroceso.

Sobre si el software empresarial tiene que funcionar bien y no necesariamente ser bonito opino que: nadie puede ser buen programador si ignora la reacción emocional que sus programas causan en los usuarios. Escribimos programas para que alguien los use (o los sufra). Bueno, si, algunos escriben módulos de control para satélites, pero no me refiero a ese tipo de software, sino al típico software de gestión que debe necesariamente interactuar con humanos.

Los que reclaman más métodos formales y algebraicos y menos giliflauteces, deben entender que la programación no es simplemente una variante de las matemáticas, porque en el momento en que entra el juego el factor humano, la idoneidad del programa realizado deja de ser rigurosamente medible.

En un mundo utópico los programas son bellas estructuras matemáticas y el arte de programar consiste en emplear el intelecto para reducir la complejidad, abstraer y sintetizar.

Pero en el mundo real las cosas están pensadas para ser simples, porque si fueran complejas no podríamos manejarlas en el día a día. Las herramientas están pensadas para que le des al botón de crear formulario, pegues unos cuantos controles visuales dentro, escribas un poco de código para procesar los eventos y a las seis te vayas a tu casa a jugar con tus hijos sin tener ni la menor idea de lo que es un puntero.

Y los usuarios no sólo quieren que el software funcione, quieren que mole y que les divierta. Porque ¿quién dijo que el daño económico que causa un bug es peor que el daño psicológico que causa no poder poner la foto de tu perro como fondo de pantalla?

Por último, haré una afirmación aún más radical, lo que diferencia a un programador bueno de uno sobresaliente no es su capacidad para buscar soluciones lógicas, sino su capacidad para buscar soluciones ilógicas. Me explico: cuando tiene delante un problema que tiene pies y cabeza, cualquier ingeniero cualificado puede atacarlo aplicando alguna determinada metodología y, con el paso del tiempo, tarde o temprano lo acabará resolviendo. Pero, de vez en cuando, se presentan problemas totalmente desconcertantes y aparentemente sin sentido. Puede, por ejemplo, que el ordenador haya sido infectado por un virus sibilino. Entonces es posible perder horas persiguiendo un bug fantasma hasta que alguien llega y dice ¡hey si no es el programa lo que funciona mal entonces debe ser otra cosa! y con dicha hipótesis ad-hoc completamente infundada dispara un proceso de pensamiento lateral de búsqueda de soluciones en las que no se había pensado. Algo así como cuando alguien dijo ¡hey, y si deterioramos la calidad de la imagen? Y entonces se inventó JPEG (sin menosprecio de su fundamento en la teoría de información) o cuando Steve Jobs se pregunto ¡hey, porqué todas las letras de la pantalla tienen que ser de ancho fijo? Los programadores comunes pierden horas buscando una explicación aparente razonable a un problema que les trae muertos. Los programadores de élite huelen el problema y buscan un atajo, es casi como si diagnosticaran el error con la punta de su nariz antes que con el cerebro.

Comentarios
1 Mariano KIWO Carrizo
31 enero 2008, 19:17

Excelente nota. No me he tomado el tiempo aun de leer los artículos citados desde aquí, pero estaba al tanto de el tema.
Como desarrollador de mitad de generación, ya que hace 7 años estoy en el rubro y no me considero un “nuevo” programador, creo que no se debe criticar a las nuevas metodologías de programación, hablo de utilización de frameworks y librerías adicionales, ya que quienes dicen que es mejor programar con punteros y calibrar todo a mano es programar de verdad no son mas que resentidos de una época en la que no disponían de esas herramientas y hablan como nuestros abuelos al recordar lo dura que fue su infancia solo por que la época hacia que la sociedad fuera tan rigurosa.
Aunque no desestimo lo que dicen de que hoy quienes están en una carrera de tecnología o sistemas aprenden un simple código y ya se creen programadores de alto rango, cuando de verdad la experiencia es lo que marca al nivel de un programador calificado.
Es un gran debate, y creo que llendo mas al punto de partida de la nota, me parece que lso programadores deberíamos tener en cuenta la parte visual y darnos cuenta que hay un cierto “marketing” en la aplicaciones, solo por citar tenemos al amigo Windows que enamora a simple vista con una interfaz bonita que hace ameno de utilizar al publico “común” de las computadoras, y solo con pensar eso podríamos darnos cuenta que si contempláramos la parte visual en las aplicaciones, tendremos clientes mas satisfechos y aplicaciones mas vendibles que, aunque esten mal programadas (todo el mundo sabe que windows tiene muchos defectos pero los siguen usando) una buena cara ayudara a sostenerlo.
Como experiencia, actualmente estoy desarrollando una aplicación de consulta para médicos íntegramente en Flash, con una interfaz muy bonita y creanme que el cliente esta mas que feliz con los coloridos de su aplicación.
Saludos desde Argentina!


2 Sergio Montoro Ten
1 febrero 2008, 11:43

Prueba Adobe Flex. Para desarrollar aplicaciones rich-client que corran 100% sobre web es de lo mejorcito que existe en la actualidad. Siempre y cuando estés dispuesto a casarte con Adobe, claro.


3 Yeradis P. Barbosa Marrero
2 febrero 2008, 08:52

Saludos y buen dia
una vez mas entre ya otras
TE FELICITO POR TUS ESCRITOS
aunque te he de criticar que este con mucho menos calidad que otros (que atrevido que soy :-S )

Realmente en la mayoria de las cosas que planteas estoy de acuerdo, aunque no dejo de creer que haya momentos en que utilizar un framework para trabajar una capa X del diseño no esta mal ya que te permite abstraerte en lo que realmente es importante y no en lo que muchos caen y es reinventar la rueda , porque hacer lo que ya esta hecho ???? cuando lo mas seguro es que la ruedad que estes usando uno no la podra hacer mejor.

Por otro lado es cierto tambien que hay frameworks monumentales que lejos de ayudar en la resolucion de una necesidad lo que hacen es crear otra y es la de primero entender como es que va la plataforma despues usarla y por ultimo ver que dicha base de herramientas no sacrifiquen funcionalidad agilidad y estabilidad de lo que estamos haciendo y para esto es necesario consumir una cantidad inhumanda de tiempo de proyecto, soy de los que creo como dicen aqui en españa de BUENO= que satisfaga nuestra necesidad , BONITO = que nos deje el diseño limpio y legible y no criptico -BARATO = que no nos devia de nuestro objetivo fundamental sino que nos ponga mas cercanos a nuestra meta ,aplicandolo como es logico al ambito informatico especificamente al desarrollo de software.

Los puntos que te enviaron a escribir este articulo son contradictorios, porque si que es cierto que para el desarrollo de soluciones, de esas, de para ayer, que le vas a estar contando al programador que si desarrollarlas con herramientas de bajo nivel es mejor porque X cosas o mas cual cosas , la cosa es YA para que asi como comentas a las 6 de la tarde pueda irse tranquilamente para la casa y disfrutar de su tiempo en compañia de sus seres queridos pero no dejo de apoyar la tesis de las personas que dicen que es bueno conocer a bajo nivel como es que va todo
especificamente para aquellos que estudian la carrera de ingenieria de sistemas o informatica ya que creo que saber cuanto penaliza el despilfarro o derroche te lleva a ser consciente de lo que estas haciendo y lo que podria repercutir de no ser consciente

un ejemplo : como es que antes con solo 200 megas tenias el sistema operativo instalado y ahora necesitas mas de 2 gigas para que funcione bien ???? como es que una applicacion antes solo se llavaba 600 Kb cuando mucho y ahora mas de 15Mb una simple ventanita de “Hola Mundo”

y es mi opinion todo lo expresado claro esta
pero creo que el no racionalizar el no optimizar el no preocuparse por “cuanto como y donde” es lo que hace que hoy dia lejos de tener sistemas super optimizados tengamos sistemas que necesitamos 1Tb de disco duro y otros de RAM para poder usar el Bloc de Notas

y claro que estoy siendo muy generico pero para los que han podido programar tiempos atras saben que con 64Kb de ram era casi mas que suficiente y teniendo sistemas tan y mas complejos que muchos de los que vemos hoy dia con mucho menos recursos en todo aspecto

y para terminar

CREO QUE EL DESARROLLO DE TODAS ESAS ARQUITECTURAS MOMUMENTALES O FRAMEWORKS SI QUE ES CIERTO QUE EN MUCHOS CASOS HACE BIEN PERO CREO QUE HA HECHO MAS LO CONTRARIA

y por los otros post que han abido les recomiendo Adobe Air que por asi decirlo es un paso superior en el desarrolo de RIA por parte de Adobe

buen dia
y una vez mas BUEN TEMA


4 tenderodigital
6 febrero 2008, 14:15

Cuanto razón. El problema en el software de empresa, es que muchas veces se piensa que quienes usan los programas, son satélites que no tienen alma. Se olvidad de la usabilidad… y así les va después, que los usuarios se ponen a hacer perrerias con el programa, o no hace nada, porque aquello es un ladrillo que ni el que lo programó lo entiende.
En el software digamos comercial, hay que agradar al cliente, así que se cuidan más esos detalles. Pero esos detalles son los que hacen que un programa triunfe.


5 lorient
13 febrero 2008, 11:00

El artículo es curioso, aunque hay ciertos detalles que no estoy conforme, y algún comentario de los escritos es el puro reflejo de lo que nunca se debería hacer y la ausencia total de profesionalidad. Me refiero al comentario de Mariano KIWO Carrizo. Mariano por lo que comenta hace exactamente lo que hace la mayoría de las empresas que nunca triunfan, y es darle al cliente un interfaz bonito que oculta un software de baja calidad. Si, es un cliente en el presente, pero no es un cliente en el futuro en cuanto descubre que el programa que le has vendido va lento, esta plagado de bugs, no se puede mantener por falta de documentación (ingeniería del software). Ah, por cierto, el ejemplo de Windows no es nada bueno, Mariano dice “todo el mundo sabe que windows tiene muchos defectos pero los siguen usando”, nooo, error Mariano, ¿Que software de millones de lineas de código como tiene Windows no esta lleno de bugs?, eso mismo le pasa a MacOS, en el cual hay estudios que se le han encontrado 10 veces más errores de seguridad que a cualquier Windows, pero claro, el marketing dice que Windows es malo y MacOS no. Y no hablemos de Linux, que el boca a boca dicen que es maravilloso, pero cuando lo usas falla por todos los sitios, y encima no tiene la apariencia visual de Windows ni su usabilidad. Lo que tiene Windows entre otras cosas es usabilidad, y con esto no me refiero a que lo usa mucha gente, me refiero a que la gente aprende rápido cómo funciona el sistema operativo, cosa que no se puede decir de Linux, que tiene usabilidad cero.

¿Con todo esto que quiero decir?, que hay que ser profesional y dar un software con apariencia visual, pero teniendo en cuenta que es más importante la parte funcional y la documentación. O si no, por qué muchos bancos siguen usando software con entornos en modo texto, porque de nada vale que todo sea bonito si luego el programa no funciona correctamente y ello hace que un banco pueda perder cientos de millones.

¿De quien es el problema?, el problema principalmente es de muchas empresas, las cuales prefieren contratar a personas no tituladas que se han leido 4 libros de programación y no contratan a ingenieros que hagan “Ingeniería del Software” porque estos últimos lógicamente cobran más. En contra de lo que piensa mucha gente, un ingeniero informático no es una persona que usa un ordenador y se ha leido 4 libros de Java, no esos son intrusos y usuarios avanzados de ordenadores, un ingeniero informático es aquel que hace ingeniería, y que sabe como funciona internamente un sistema operativo, como funciona un microprocesador, como funciona internamente una base de datos, como funciona un compilador, como funciona a nivel de paquete una red, ha estudiado optimización de algoritmos(Matemáticas puras y duras), que se ha tenido que pelear con todo tipo de lenguajes como ensamblador, C, Java etc. y ha aprendido de las virtudes y defectos de los mismos, que ha tenido que programarse en sus día sus propias librerías y no se ha limitado toda su vida a usar librerías de terceros.

¿A que viene todo esto?, pues viene justamente con lo que se comenta en el artículo de Sergio. Un verdadero profesional no es el que tira código, sino el que programa sabiendo en todo momento los efectos que produce su código en el sistema operativo, base de datos, red de ordenadores, qué va a generar el compilador etc etc. Y todo ello documentado al máximo y optimizado (Mantenibilidad).

¿Qué es lo que núnca se debe hacer?, pues precisamente todo lo que dice Mariano que hace. Mariano hace software que no se puede mantener, y para hacerle una página web a una pequeña empresa que no vas a volver a ver puede ser un parche temporal y ganar un poco de dinero. Pero ese tipo de trabajo que hace Mariano, hace perder muchos millones a las empresas en el desarrollo, optimización, soporte, mantenimiento, pero claro, estamos hablando de proyectos medio/altos, de muchos millones, no chapuzas que se hacen en 6 o 7 meses.

¿Qué es lo que hacen muchos informáticos actualmente? Pues aquellos informáticos sin conocimientos del medio en el que trabajan, se limitan e meter código Java sin saber en qué repercute más allá de la información que saca el ordenador por pantalla, se limitan a lanzar sentencias SQL sobre la base de datos sin saber cómo esta trabajando esa base de datos al lanzar dichas sentencias, se limitan a enviar peticiones a los servidores sin tener en cuenta como se esta transmitiendo dicha información por la red, se limitan a tirar código sin hacer un estudio en “PAPEL” de todo el diseño, no documentan nada… Resumiendo, esos no son ingenieros informáticos, y si tienen el título que lo dudo, deberían quitárselo, porque ingeniero no es quien tiene un título, es quien actual como tal.

Concluyendo, lo mejor siempre será un software bueno, con una apariencia agradable, libre de errores, mantenible etc. Pero para hacer todo eso se necesita gente con conocimientos más alla del lenguaje de programación que se va a usar. Programar lo sabe hacer cualquiera que se compre un libro de programación, ahora, hacer software de calidad solo lo saben aquellos que han estudiado informática a fondo.


Acerca - Contacto - Información legal y técnica - Condiciones de uso - Noticias sobre el mundo del Desarrollo de Software.