Artistas del código

25/04/2012 por Carlos Burges

Desde ayer, cientos (por no hablar de miles) de sitios web están publicando  información sobre el nuevo servicio de archivos Google Drive y comparando todos los servicios disponibles, parecidos o no, y sus características. Pero hay algo más, un problema de fondo mucho más complicado que define una situación compleja entre fabricantes de hardware y desarrolladores de software que acabamos sufriendo los usuarios.

Allá por Octubre de 2007, tuve el atrevimiento de publicar una serie de artículos llamados "Charlas (apócrifas) con Steve Jobs" en las que intentaba descubrir (o adivinar) el futuro de Apple hace 5 años. En una parte de esas supuestas conversaciones, había un párrafo que sigue manteniendo toda su validez:

Durante los 15 últimos años los desarrolladores han trasladado la necesidad de un código más compacto y mejor escrito a los fabricantes, exigiendo más potencia y mejores prestaciones en el hardware. Resulta bastante increíble que programas que hacen cosas muy sencillas se coman un 10% de los recursos de un MacPro. Eso se llama mediocridad en el desarrollo, pero es algo que tenemos que sufrir, porque es un tipo de tendencia que no va a cambiar.

 

Y no, 5 años después, esta tendencia no ha cambiado. Seguimos igual, sufriendo una importante mediocridad en el desarrollo de aplicaciones debido a muchas causas: presión por sacar el producto, deadlines imposibles, imposición de departamentos de marketing que son incapaces de ver que el trasfondo tecnológico detrás de sus peticiones requiere un importante trabajo … pero sobre todo, mediocridad en el código.

Esta falta de interés, por supuesto, es parte de ese entramado empresarial en el que "los objetivos" como tales son puestos sobre todo bajo plazos absolutamente  irreales y por una política de "saquemos el producto y que marketing lo venda. Luego ya publicaremos parches cuando haya una nutrida base de usuarios y si no funciona, abandonamos y a otra cosa". ¿Te parece algo irreal?: no, no lo es. Es el pan de cada día.

Y toda esta historia viene, precisamente, por el lanzamiento de Google Drive. Mientras todo el foco de atención va al servicio, pero en la zona oscura los usuarios tenemos que sufrir la mediocridad del desarrollo. Pero observemos un ejemplo:

En el pantallazo del Monitor de Actividad de un MacBook de 2006, donde las diferencias de la "mediocridad de desarrollo" se agravan aún más, podemos ver dos aplicaciones prácticamente iguales: Google Drive y Dropbox. Sus prestaciones y funcionamiento son tan extraordinariamente parecidas que uno se pregunta: ¿por qué la aplicación de Google, haciendo lo mismo que la otra, es capaz (en parado, sin sincronización) de consumir más del doble de recursos que la otra? ¿Esto es lo que nos merecemos los usuarios o porque es gratis hay que tragarse "todo" lo que nos echen?.

Lo que está claro es que los fabricantes de hardware, en la actual sintonía de la economía mundial, no están precisamente por la labor de "tapar" con potencia bruta los problemas derivados de una cada vez más acusada falta de  código competente y estas diferencias de rendimiento se van a hacer cada vez más acusadas en los próximos años y si no, solo hay que echar un ojo al mercado de movilidad, donde las aplicaciones para móviles en ocasiones son auténticas devoradoras de recursos de hardware muy limitado porque no se depura, se mejora y se trabaja el código, ya que hay que salir deprisa y corriendo al mercado para hacer beneficios. Y como solo vale 0,79 € (o es gratis) … pues por ese precio, ¿qué quieres?.

Hace falta un cambio de actitud. Empezando por los programadores. Pero también por los usuarios, desplazando fuera los desarrollos defectuosos. Se acabaron esos tiempos del todo vale, porque en las circunstancias actuales, las inversiones cada vez son más reducidas y un error, por mucho que se redimensione, será fatal para el extremo de la cadena, que es el que pone la pasta para que toda esta maquinaria funcione.

0
Comentarios
  • #1 por imacarron el 25/04/2012
    No soy programador, pero no podría estar más de acuerdo con lo expuesto en este artículo. Las causas de estos "problemas" están cada vez más arraigadas en todo el tejido empresarial de nuestro país (y también en el de otros, vaya, que no somos los únicos), y claro, así nos va...
  • #2 por rafacintosh el 26/04/2012
    Completamente de acuerdo. Si se optimizara el sotfware y estuviera bien depurado se aprovecharían mejor los recursos del hardware. Simplemente hacer las cosas bien.
  • #3 por linzanet el 26/04/2012
    Vale, totalmente de acuerdo. ¿Pero cómo sabemos los usuarios "de a pie" cuál está bien programada y cuál no, si me viene justo para saber dónde están los programas del sistema?
  • #4 por wenmusic el 26/04/2012
    Adobe en general es un perfecto ejemplo de ello.
  • #6 por neyrh el 26/04/2012
    Buenas noches,
    pese a estar de acuerdo con la mayoría del artículo, hay una parte en concreto que no creo que sea fiel a la realidad, y me parece conveniente comentar:

    "Hace falta un cambio de actitud. Empezando por los programadores."

    Yo no sé hasta que punto el sr. Carlos Burges sabe de programación o se ha dedicado a ello(comercialmente quiero decir), pero yo sí sé lo que es, y lo que se tiene que comprender es que, el control del timing para la entrega de un proyecto, normalmente no lo pone el programador, y si tiene la suerte de poder marcarlo (inicialmente únicamente), no se lo respetan,
    sin embargo, también hay que decir que hay mucho programador chapuzas, eso es innegable, pero los que no lo somos, a veces vamos tan apretados con los tiempos que nos marcan, que como comprenderás, la fase de optimización se deja para cuando "los jefes" te lo permitan, cosa que muchas veces ni tan siquiera llega a suceder.

    Es triste sí, pero los que tienen que cambiar de actitud son los gerentes, directores y supervisores(etc.), que piensan demasiado en la comercialización del producto, sea cual fuere su estado de desarrollo, y más aún cuando se trata de optimización de código, que a la mayoría de personas les suena a chino, o a excusa barata para perder el tiempo, o sencillamente piensan que es una tontería y que no vale la pena perder el tiempo en ello.

    A esto también decir, que el consumidor también tiene gran parte de culpa, pues busca un software de lo mejorcito, pero que le salga a duro y medio, y como no se está dispuesto a pagar por un desarrollo en condiciones pues pasa lo que pasa, el pez que se muerde la cola que todos ya sabemos.

    Aunque no lo parezca, los programadores(generalizando bastante) son personas sobreexplotadas y con un trabajo que se menosprecia bastante a menudo (especialmente en españa), cosa que también es triste.

    Por último, sólo comentar que hacer un código a prueba de usuarios(que también de fallos), es muy difícil(hablando por ejemplo de un sistema operativo), y en este mundo de inconformistas(pero según para qué) en el que vivimos, blindar un sistema para evitar que los "usuarios" metan "mierda" en el sistema(aunque al final la acaben metiendo) y que así sea "un poco" más estable está mal visto ... véase iOS.

    Buenas noches y muchas gracias a todos.
  • #7 por Carlos Burges el 27/04/2012
    #6 Desgraciada o afortunadamente, el Sr. Carlos Burges si se dedica "al código": a venderlo, a gestionar proyectos y a sufrir todo lo relacionado con ello. Y lo sufre "casi en silencio", como las hemorroides.

    Un abrazo