Los usuarios y la primera impresión

Repasando la pila de cosas pendientes de leer me he encontrado con un inspiradísimo Larry O'Brien en una frase que es solo lateral en su razonamiento de que se nota más a los programadores muy malos que a los muy buenos

Medir la satisfacción [para medir la calidad de un desarrollo] es un indicador insuficiente, porque la satisfacción tiende a ser un delta de la última experiencia, no un valor absoluto.

Y es curiosísimo, porque tengo exactamente esa percepción tanto en un lado como en el otro, de programador y de usuario: no importa lo que ocurra posteriormente a un error fatal del sistema; el sistema llevará para siempre ese estigma. Da igual que se corrigiese para siempre, en la siguiente versión. Para no ser absolutamente pesimistas, a nivel interno ayuda muchísimo que exista (y se use) un sistema de seguimiento de incidencias, que esté documentado cuándo, dónde y cómo se producía el problema y cuándo (desde que versión) y cómo se solucionó. A nivel externo... ya digo, un estigma :/ Aunque una labor continuada de comunicación, que tal mal se les suele dar a los desarrolladores, puede ayudar bastante...

Es también por el miedo a que la primera impresión no sea buena por lo que muchos programadores se resisten al famoso release early, release often. Pero no publicar versiones también es fuente de mala imagen, de eso los desarrolladores deben de ser conscientes... Y es que es difícil conjugar el causar una buena impresión con publicar pronto. Yo tengo en esto una política que no sé si es la más acertada, pero es la mía: minimizar la funcionalidad de la primera iteración, limitarla a lo esencial, que sea mínima pero bien testeada. Por cierto, que Joel no está de acuerdo con esta estrategia desde el punto de vista estratégico/comercial/ISV... Mucho que discutir desde distintas vertientes, incluido el modelo de negocio y de desarrollo de software, claro :)

Por cierto que este mismo tema, desde el punto de vista estrictamente estético, fue tratado por Jeff Atwood con un ejemplo muy desafortunado, comparando Frets on Fire con Guitar Hero. No puedo ser imparcial en este caso porque estoy enganchado al FoF en el que uno se puede creer que toca con el teclado como Stevie Ray Vaughan con su guitarra en Texas Flood. Aquí, al menos para mi, es el sonido y no la imagen lo importante :)

Los usuarios y "la primera impresión" en barrapunto

Problemas de memoria (y algunas soluciones)

Gracias a Lambda The Ultimate he encontrado un artículo muy ilustrativo sobre el típico flame de gestión automática de memoria contra gestión manual: Quantifying the Performance of Garbage Collection vs. Explicit Memory Management de Matthew Hertz, Yi Feng, Emery D. Berger. Si hacemos caso de sus conclusiones:

Si las aplicaciones se ejecutan en sistemas con al menos tres veces más memoria RAM de la necesaria entonces la recolección de basura proporciona un rendimiento razonable. Sin embargo si el sistema dispone de menos RAM o las aplicaciones tienen que competir con otras por memoria entonces se debe esperar que la recolección de basura traiga consigo un coste de rendimiento sustancial.

Como es sabido, no es blanco ni negro, sino que es una cuestión de compromisos, pero al menos ahora tenemos algún dato para tomar la decisión. De todos modos el artículo tiene más cosas que esta conclusión: compara diversas estrategias de recolección de basura y tiene muchas referencias interesantes.

A raíz de una de esas referencias me he encontrado con un asignador de memoria dinámica (allocator): hoard, curiosamente desarrollado por Emery Berger, uno de los autores del artículo anterior. Este asignador promete evitar uno de los grandes cuellos de botella de la programación con threads y sistemas multicore: la gestión de la memoria dinámica, el heap. Citando también del primer artículo:

En particular, las versiones recientes de hoard mantiene en el espacio local del thread la lista de los espacios libres (freelist) y usa generalmente operaciones atómicas sólo cuando se sincronizan o se rellenan.

Muy interesante...

Problemas de memoria (y algunas soluciones) en barrapunto

Recursos para optimizar programas en C++ y ensamblador

Ya se sabe, la optimización prematura es la raíz de todo mal. Pero hay veces que es necesario optimizar y en estos casos no viene mal una ayuda... Por un lado conocer la estructura de las arquitecturas modernas de uso común en cuanto a memoria y cachés. De eso ya se ha encargado Ulrich Drepper como hemos comentado hace poco por aquí.

Por otro lado, he encontrado gracias a programming.reddit una serie de recursos entre los que se encuentran documentos en pdf que podrían ayudarnos. Todos ellos están escritos por Agner Fog y están reunidos en Software optimization resources. Son bastante extensos y por lo que he ojeado con bastante información valiosa. De ellos destacaría (es el que más he mirado), Optimizing software in C++ (An optimization guide for Windows, Linux and Mac platforms) (pdf) que repasa formas de optimizar C++ reparando además en particularidades de plataformas y compiladores.

Además hay también una guía para para optimizar ensamblador para plataformas x86, tablas con características de las instrucciones de Intel y AMD, programas de test y más enlaces. A disfrutar con la lectura, pero a usar con precaución ;)

Recursos para optimizar programas en C++ y ensamblador en barrapunto

Lo que todo programador debería saber sobre la memoria (pdf)

Ulrich Drepper ha acabado de publicar online la serie de artículos acerca de la memoria, cachés en arquitecturas modernas de uso común y de lo que el programador puede hacer al respecto. Cuando comenzó ya lo comentamos por aquí en Lo que todo programador debería saber sobre la memoria.

Y como prometió lo ha publicado ahora en pdf: "What Every Programmer Should Know About Memory" por Ulrich Drepper. Como puede ser que alguien interesado no se haya enterado de su existencia, la aparición del pdf puede ser un buen momento para recordarla...

Lo que todo programador debería saber sobre la memoria (pdf) en barrapunto

Programando con threads: algunos enlaces

Algunos enlaces a tener en cuenta si programas con threads:

• "Avoid Calling Unknown Code While Inside a Critical Section" por Herb Sutter. Como simepre, las secciones críticas cuanto más pequeñas mejor, pero además conviene saber qué es lo que se llama en ellas... (Me recuerda un poco al mantra Trata el código de los demás como si fuese tuyo)
• "Single Threaded Memory Model" de Ian Lance Taylor: como comentaba hace ya mucho en Los peligros de programar con threads el compilador puede llegar a hacer optimizaciones que den al traste con la intuitiva atomicidad de algunas variables cogidas por mutex. Pues bien, aparentemente ese problema que podría parecer remoto se puede reproducir con gcc. La solución, como siempre, conocer bien el estándar y el uso de volatile. De todos modos queda patente que se necesita algo parecido a un modelo de memoria que tenga en cuenta la concurrencia, como se comentaba también en Threads y C++(estándar)

Programando con threads: algunos enlaces en barrapunto

El programador (una apología)

Me apetece hacer apología del puesto de programador, porque creo que es necesario por dos motivos fundamentales y relacionados: no se le considera un puesto apetecible por ser jerárquicamente bajo y no se tiene conciencia de que la experiencia en la programación sea útil. En resumen, que el puesto de programador no se considera de futuro[1]. Pero no es el futuro profesional del programador[2] de lo que quiero hacer apología, sino de la labor del programador en si: difícil pero necesaria y apasionante[3].

Los buenos programadores son imprescindibles para que este mundo funcione. En la eterna, manida y estéril discusión de las atribuciones profesionales se suele denostar la labor de programador en favor de la figura del arquitecto de software. No voy a entrar aquí en lo importante de una buena dirección y coordinación en un proyecto de desarrollo (que lo es), sino de lo importante que es el trabajo de base. Porque el de programador en un puesto intrínsecamente bajo desde el punto de vista jerárquico. ¿Significa eso que es un trabajo rutinario, sin retos ni creatividad? En absoluto. Es un trabajo muy decisivo, a veces creativo y de gran responsabilidad casi por definición.

Es difícil porque hacer software es intrínsecamente difícil[4][5] Y el creer que toda la dificultad se puede abstraer del programador hacia arriba en la jerarquía no deja de ser una especie de pensamiento mágico alejado de toda realidad. Es prácticamente imposible hacer un análisis y diseño completos sin resquicios y teniendo en cuenta todos los detalles del sistema final, tanto funcionales como de rendimiento y seguridad. Es muy frecuente que aparezcan aspectos dependientes de que la implementación sea óptima y adecuada al uso del sistema final.

Es de una gran responsabilidad porque, entre otras cosas, es muy fácil hacerlo mal y no es trivial descubrirlo[6]. El programador moldea con sus manos el sistema final que va estar funcionando, transforma en realidad, en funcional, un concepto ideal. Y es el que más directamente que se da de bruces con las limitaciones del mundo real, de las herramientas y los sistemas. Es el que, si es brillante, es capaz de dar soluciones a esas limitaciones o al menos no acrecentarlas. Pero un programador no muy hábil o simplemente poco disciplinado o descuidado puede provocar errores, tanto fáciles de detectar como demasiado sutiles para ser detectados cuando deben, en la fase más temprana posible del desarrollo.[7]

Tengo que decir que lo que yo entiendo por programador es lo que a veces se denomina "desarrollador", algo un poco más amplio que solo tirar líneas, pero me niego a renunciar a usar el término: me gusta decir programador, me gusta programar.

[1] Y es posible que no lo sea :( Me gustaría pensar que, por lo que cuento después, lo es.
[2] Bueno, hay muchos futuros dentro del desarrollo. Uno, ascender. Otro, especializarse. Pero bueno del futuro profesional prefiero que hablen los comentaristas...
[3] Obviamente hay mucho que comentar de los aspectos sociales del programador, que pueden condicionar, pero no hablaré de ellos. Para saber más pasa por aquí ( bueno, o por aquí)
[4] "The complexity of software is an essential property, not an accidental one. Hence, descriptions of a software entity that abstract away its complexity often abstract away its essence" No silver Bullet, Frederick P. Brooks
[5] Un poco más actual: Software Is Hard, Kyle Wilson
[6] Me gusta mucho la frase de Brian Kernighan: "Depurar es el doble de difícil que escribir el código por primera vez. Entonces, si escribes código tan inteligentemente como te sea posible, no vas a ser, por definición, suficientemente listo para depurarlo" Depurar es otra habilidad quizás no demasiado valorada del programador experto.
[7] Metodologías de desarrollo y/o testeo adecuadas y acordes con el proyecto aceleran la caza de errores, pero la disciplina y experiencia del programador son la base del desarrollo de calidad.

"El programador (una apología)" en barrapunto

¿Está acabando internet con el contenido extenso?

Se suele recordar mucho últimamente que el vídeo mató a la estrella de la radio por aquello del cambio de formato y de la (no) adaptación de la industria musical a esos nuevos formatos. Lo mismo seguramente se puede ampliar al resto de los contenidos culturales, en el amplio sentido de la palabra, y sobre todo al libro ¿Mató internet el contenido extenso? ¿Mató internet a los libros?

El caso es que últimamente he visto varios casos en los cuales el modo de publicación es controvertido porque se trata de contenidos de un volumen grande, más grande que un post de blog, para entendernos. Primero fue Ulrich Drepper que dudó que opción tomar y tomó la resolución de publicarlo por partes en LWN. Ian Lance Taylor ha publicado un número enorme de post, veinte, muy interesantes (para mi al menos ;) ) sobre enlazadores, pero demuestra claramente que el blog no sirve para crear contenidos amplios y legibles a la vez.

¿Cual es la tendencia? Hemos visto decaer sitios de generación y promoción de contenidos que premiaban calidad y extensión, como k5 o libertonia. Triunfan sitios del tipo digg, reddit o meneame en los que sólo se hace referencia y se extracta brevemente. No se me entienda mal, los sitios me parecen útiles, programming.reddit y tecnologia.meneame los visito y uso. Pero creo que tienden a ser autocontenidos, a quedarse más en si mismos que a servir para lo que probablemente deberían servir: promocionar contenido de calidad. Es la tendencia al minimalismo, tanto en la referencia como en el comentario: estos sistemas premian la brevedad y la concisión, con buenas razones, pero en perjuicio de contenido espeso y en favor del impactante. /. en las dos versiones que uso estaría a medio camino, pero no se acaba de librar de este mal... Es el signo de los tiempos, en los que la sobrecarga informativa va acompañada de atención parcial continuada...

Pues bueno, Charles Petzold, que escribe mucho mejor que yo y que además tiene un buen curriculum de libros espesos publicados reflexiona sobre ello en Hard Work, No Pay: What's the Point?, teniendo en cuenta que lo hace, al menos en parte, desde el punto de vista de un autor. Se pregunta ¿por qué libros y no entradas en blogs? Y responde (citraduzco un poco al vuelo)

Es fácil convencerse de que los pedacitos de prosa representan el nivel óptimo de granularidad de información. Es parte de la visión utópica de la web como una plétora de páginas débilmente enlazadas cuya sinergia genera toda la información que necesitamos. Esta ilusión está afectando a la manera en la que aprendemos y tengo miedo de que no tengamos una visión más amplia y completa que solo un libro puede proporcionar. Un buen autor encontrará una selva poco manejable de información y cortará una senda coherente para pasar a través de ella, a través de una narrativa que enlaza el material.

Respuesta que me ha gustado mucho porque ilustra muy bien el tipo de libros que deberían sobrevivir a la mencionada sobrecarga informativa: aquellos que son capaces de establecer un poco de orden y hacer un poco más comprensible la realidad fragmentada.

¿Está acabando internet con el contenido extenso? en barrapunto

Lo que todo programador debería saber sobre la memoria

Así titula Ulrich Drepper un artículo sobre los posibles cuellos de botella que se generan en las arquitecturas modernas de uso común, explicando el comportamiento de las caches de CPU, el diseño de los controladores de memoria, el DMA... Debería ser útil para esos momentos en los que las abstracciones que usamos empiezan a fallar y debemos conocer lo que hay debajo.

El modo de publicarlo es un poco, bueno, llamémosle arcaico, pero nos conformaremos porque el contenido lo merece, y porque es el deseo del autor, claro... El caso es que se va a publicar por partes en LWN.net y al comienzo serán accesibles solo para suscriptores y posteriormente para el resto. Al final publicarán la versión pdf que probablemente será muy interesante para imprimir. Actualización (22/11/07): Ya está disponible la versión en pdf: "What Every Programmer Should Know About Memory" por Ulrich Drepper

He ido actualizando esta entrada conforme se han liberado las todas las partes del documento, muy interesantes:

• What every programmer should know about memory, Part 1
• Memory part 2: CPU caches
• Memory part 3: Virtual Memory
• Memory part 4: NUMA support
• Memory part 5: What programmers can do
• Memory part 6: More things programmers can do
• Memory part 7: Memory performance tools
• Memory part 8: Future technologies
• Memory part 9: Appendices and bibliographys

Bonus Track: Como creo que pega en esta entrada, pongo el link a unas charlas con diapositivas de Herb Sutter sobre temas similares: Machine Architecture: Things Your Programming Language Never Told You (jejeje, Sutter y Drepper ¿lo mejor de los los dos mundos?)

Lo que todo programador debería saber sobre la memoria en barrapunto

Paul Graham Facts

Paul Graham Facts. Sólo apto para quien sepa quien es Paul Graham (bueno, y aún así...) Ejemplo: Paul Graham is so good, he always tips using $2.56 cheques made out by Donald Knuth

Actualización: por si alguien es tan masoquista de quedarse con ganas de más: Bruce Schneier Facts. Espero que me sepan perdonar :)

Paul Graham Facts en barrapunto

Intel anuncia un compilador con memoria transaccional

Intel está trabajando en un compilador que gestiona memoria transaccional y que está ya en estado de prototipo. Al parecer se puede descargar y usar y para hacernos una idea ponen un miniejemplo de uso. Parece que esta tecnología está saltando de la investigación académica a la industria, habrá que ir viendo lo que da de si, porque, como ya comenté por aquí, hay gente que no acaba de verlo claro.

Intel anuncia un compilador con memoria transaccional en barrapunto