Por qué el núcleo Windows NT es peor que Linux: problemas sociales y de incentivos

En el artículo “I Contribute to the Windows Kernel. We Are Slower Than Other Operating Systems. Here Is Why.” se transcribe el comentario (luego eliminado) de un anónimo que se identificó y aportó pruebas como programador de Microsoft. En el comentario explica su opinión de por qué el núcleo Windows NT (el que se usa en todos los siguientes, 2000,XP, Vista, 7 y 8). Más allá de las anécdotas, y de que es una visión parcial y subjetiva, es muy interesante lo que desvela. En pocas palabras, la carencia de calidad y eficiencia son más un problema social más que técnico:

• Falta de incentivos, o incentivos equivocados.
• Dar mayor importancia a cumplir los planes establecidos sin desviaciones que aceptar cambios no planificados para mejorar la calidad del producto.
• La carencia de programadores con experiencia, o el exceso de programadores recién graduados.

Es muy interesante la lectura, desvela los problemas de gestionar y programar sistemas complejos. Cualquier economista explicaría que hay que establecer los incentivos adecuados, sobre todo en entornos como la programación donde se trata de desarrollar sistemas tan complejos que tienen más componentes que el avión más grande del mundo y tantas formas de interacción -muchas órdenes de magnitud superior a cualquier sistema de componentes físicos- que escapan a nuestra capacidad de comprensión.

Ese incapacidad cognitiva de siquiera conocer la magnitud de la complejidad hace que sea imposible hacer un diseño inicial que tenga en cuenta todas las interacciones y casos. Por ello es imposible asegurar que no haya bugs y, por supuesto, que el sistema desarrollado sea eficiente. Eso requiere, tal como ya lo contaba Brooks en los ’70, el “mantenimiento” de los programas, que consiste en la mayor parte del ciclo de vida del software. Ese mantenimiento no consiste sólo en arreglar problemas, también en mejorar el código (para controlar mejor la creciente complejidad) y la eficiencia.

En el núcleo Linux es un buen ejemplo en ese sentido: se usaron las ideas y principios de modularidad de Unix, es software libre con todo a la vista del público (el código, y las discusiones técnicas), la gestión de Linus Torvalds (y los responsables de módulos) han creado una comunidad muy meritocrática (talk is cheap, show me the code) donde el respeto a los clientes (desarrolladores de programas a nivel usuario) es prioritaria, revisión de pares, se debate con dureza cada propuesta y cambio, se critica duro al que presenta propuestas malas, pero también se reconoce y halaga al que consigue mejorar funcionalidades ya establecidas y maduras.

Esa es una de las principales diferencias que se extraen del artículo.

En Microsoft [presuntamente] no funciona así, los responsables de módulos tienen más razones para rechazar mejoras que para introducirlas,  los Project Managers no ven con buenos ojos que haya desvíos del plan de trabajo, los grupos de testing no quieren saber nada de volver a probar y adaptar unidades de verificación. Es decir, no hay incentivos para mejorar las funcionalidades existentes y que no sean prioritarias en la empresa. En consecuencia, la eficiencia de sistemas con modelos de desarrollo más similares a Linux acaban siendo superior, sobre todo en las áreas y funcionalidades ya maduras.

Otro de los problemas que se menciona es el abandono de los programadores senior y la contratación de nuevos que acaban de salir de la universidad. Estos no son capaces de valorar la complejidad del sistema, ni de conocer por qué fueron tomadas las decisiones técnicas anteriores.

Este último punto es interesante, sobre todo en un gremio -y en un país- donde se valora poco la experiencia de los programadores. Salvo las empresas punteras en desarrollo de software equiparan los [excelentes] salarios de los programadores con la de los gestores (no es nada raro que un programador senior de Google cobre 150.000€). Ocurre en muchos países, pero sobre todo en España, tener 40 años y seguir programando parece más un fracaso profesional que el éxito de un programador apasionado.

Tampoco es culpa de las “empresas” o el “mercado”, desde la propia universidad solemos transmitir el mensaje equivocado:

Un ingeniero informático no programa, dirige proyectos

Ese mantra lo oí muchas veces y los alumnos lo escuchan frecuentemente en clases. El error es múltiple, por un lado transmitimos la idea que un ingeniero graduado sabe todo lo necesario, que no hace falta experiencia en programación, y que programar es de pringaos.

Además de lo mejorable que es nuestra educación, y como últimamente me está apasionando el tema de gestión de desarrollo de software, del comentario me han quedado algunas cosas más claras:

• Los planes y metodologías son herramientas, no un fin en sí mismo, como terminan de creerse sus responsables y evangelistas.
• Se deben crear incentivos, no sólo monetarios, para motivar a que los programadores desarrollen mejoras para cualquier parte del sistema. Esto implica, entre otras cosas, descontar un porcentaje de los recursos disponibles para implementar nuevas funcionalidades y reservarlos para mejora de la “calidad global”.
• Valorar debidamente a los programadores experimentados, que empieza por reconocer -sobre todo entre nosotros mismos- las carencias inevitables de un recién graduado, y la rápida evolución de la ciencia y tecnologías informáticas.
• Debemos empezar a esforzarnos en formar a profesionales cuyo objetivo sean jubilarse como programadores, no sólo un camino intermedio para lograr mejores salarios en otros puestos de gestión o dirección.
• Sobre todo, reconocer que tenemos problemas cognitivos para visualizar mental y adecuadamente la enorme complejidad de los grandes sistemas informáticos.

Lo que se aprende, o debería, en la carrera de informática

En mi apunte anterior “Lo que demanda el mercado…” critiqué la obstinación de algunas autoridades universitarias, especialmente las de la mía, en su posicionamiento extremamente conservadora contra el GNU/Linux… y cómo el tiempo les ha quitado la razón (yo diría que debería haberles avergonzado). A pesar de los dos enlaces que puse en la posdata, muchos interpretaron que pensaba que la universidad debe enseñar GNU/Linux porque tiene más salida laboral. Otros opinaron (sobre todo en Twitter) sobre lo poco que se aprende en la universidad de las últimas tecnologías [de moda].

Hace cinco años escribí un apunte muy largo sobre este tema: Sintonizar universidades y empresas, pero ¿qué debe saber un ingeniero? (y hay más, de gente más importante y valiosa que yo, como ¿Qué deberíamos enseñar a los nuevos desarrolladores? de Bjarne Stroustrup), ahora intentaré ser muy breve para contestar a esos dos temas.

SpokenPic liberado

Resumen para vagos: el código liberado de la app SpokenPic está en Github. Punto

Hace unos días fue la presentación del Galaxy S4, entre otras cosas mostraron su “novedosa” y “exclusiva” aplicación para poner voz a las fotos, muy similar al SpokenPic (prometo que sonreía, no hay mejor halago que una gran multinacional tecnológica haga algo igual casi un año después, y que lo presenten en un gran cutre show como una “innovación”). Eso me hizo acordar que habíamos prometido liberar el código,  que estaba prácticamente abandonado.

El SpokenPic fue un fracaso, sin paliativos[*]. Aunque tiene buenas críticas y estrellitas en Google Play, sólo tuvo 2.000 descargas, y ahora hay sólo 600 instalaciones activas. Aunque nos llevó dos meses de trabajo a tope (no sé cómo sobreviví haber pasado tantos días durmiendo sólo 4 horas, y dándome de hostias con el Java, el API de Android, y hasta la documentación oficial errónea de la cámara), hasta con lanzamiento grupal emocionado (foto de la derecha), lo cierto es que no caló, y que no tuvimos tiempo para mejorarlo, ni siquiera en las funcionalidades que teníamos previstas (como la de clips con múltiples fotos). Visto en retrospectiva, fue el desánimo que nos desmotivó.

“Particionado funcional” económico en Amazon RDS… y cachea todo ¡estúpido!

El miércoles pasado di una charla de cómo tenemos Menéame en Amazon AWS. Iba a explicar, al final de la charla, un truco de “particionado” [ver nota al final] económico, pero que no pudo ser: me tocó vivir en directo una saturación de la base de datos, producida por el nombramiento del nuevo Papa. Ahora explico cuál es ese “truco” de “particionado” económico y sencillo que sirve para ahorrar costes en RDS, y luego qué pasó y cómo solucioné la saturación de una de las bases de datos (de allí la frase “cachea todo ¡estúpido!”, el estúpido soy yo ).

La base de datos principal de Menéame está en MySQL sobre Amazon RDS, con Multi AZ, lo que significa que tenemos failback y failover over automático y desantendido si el master falla. Da mucha comodidad, pero también tiene su coste: se paga el doble (el tamaño que tenemos es el large).

Un par de bellezas de algoritmos distribuidos que deberías implementar tú mismo

Antes de irme a acostar pensé: “En vez de escribir quejas o de temas políticos-sociales, ¿qué tweet puedo dejar sobre temas de programación que entusiasme y sirva de algo a un programador”. Lo hice, pero luego pensé, son tweets a las 2:30 de la madrugada, los leerán sólo un par de insomnes frikis que no salen de marcha un viernes. Así que mejor lo dejo en mi blog (no pondré ningún enlace, todo está en Internet y es fácil encontrarlo con los nombres).

Este año me tocó dar Programación Concurrente y Distribuida, por lo que tuve que dedicar tiempo no sólo a aprender los algoritmos, sino a estudiarlos en profundidad para poder explicarlos, responder a todas las preguntas posibles, y además diseñar las prácticas en laboratorio. Así, de tanto estudiarlos llegó un momento que dije ¡hostia, que guapo y simple es!. Me pasó con el algoritmo de Chandy-Lamport para ”snapshots” de sistemas distribuidos.

El estado de un sistema distribuido en un momento dado es imposible de obtener, ni tiene sentido. Pero sí que tiene encontrar un “estado consistente”. Este estado se refiere a qué mensajes se enviaron desde cada nodo (u ordenador), y qué mensajes estaban en tránsito en cada arista (o canal de comunicación). Es lo que hace el algoritmo de Chandy-Lamport. Si estás flojo en algoritmos distribuidos, o no recuerdas, o piensas que es muy complicado, te recomiendo que lo implementes. Es una “belleza”, en muchos sentidos. Pero mejor que lo saborees tú mismo

Alerta

Implementar y probar algoritmos distribuidos en un único ordenador suele ser un coñazo. Hay muchos sistemas, pero hay que aprenderlos. Yo encontré que lo mejor es un sistema de paso de mensajes distribuidos, pero usándolo desde un único ordenador. Creo que no hay sistema de mensajes más simple, y con librerías para casi todos los lenguajes, que el Beanstalkd. Te lo recomiendo. De paso aprendes los conceptos básicos de estos sistemas, si es que no lo sabes. Recomendación: que cada nodo tenga un canal (o tubería en terminología beanstalkd) para recibir mensajes hacia él, es lo más simple, y simula perfectamente un sistema distribuido (cada nodo puede ser un proceso, o un hilo, tanto monta, siempre que las variables de los algoritmos no sean compartidas).

Quizás es recomendable implementar antes el algoritmo de “terminación distribuida” de Dijkstra-Scholten. Se usa la misma estructura de procesos y colas de mensajes, es más sencillo de entender (creo), y también es un algoritmo guapo.

Si implementas esto, y los entiendes, será como andar en bicicleta, no te olvidarás más. Y te gustará más la informática

Firefox OS, y expresiones de deseos más que realidades

Antonio Ortiz publicó en Xataka una entrevista a Carlos Domingo, CEO de Telefónica I+D. Por referencias, Carlos parece un ben profesional, pero critiqué en Twitter el lenguaje tan corporativo y vacío, en el sentido que se repite frases típicas, y no desvela nada interesante. A raíz de esos comentarios, tuve varias respuestas, repitiendo otra vez frases vacías y wishful thinking sobre lo que es Firefox OS, y su “innovación” en el mercado de móviles.

En primer lugar debo decir que me gusta mucho la creación de Firefox OS, por varios motivos.

Cálculo comparativo de la diversidad de votos mediante densidad de grafos

En Menéame teníamos desde 2008 un control de diversidad de votos. Éste se basaba en el control de los votos de los usuarios al autor de un envío, se tomaba en cuenta el porcentaje de noticias votadas al mismo usuario. Aunque cumplió con su papel, claramente era insuficiente. Las críticas de que un grupo de personas podían conseguir una “ventaja” de lo que salía en portada tenían algo de razón. El control existente no hacía un control más global, es decir, grupos de personas con un mismo patrón de votos, por lo que intencionadamente o no, si hay un centenar de personas muy activas y afines entre ellas, éstas consiguen que sus noticias se publiquen con mayor facilidad.

Llevaba años pensando en una solución al problema. Los algoritmos y técnicas usadas son en general basadas en “corpus completo”, se construye un grafo o sus correspondientes matrices con la información completa que se quiere analizar. Para ello se pueden usar algoritmos de clustering, centralidad y/o afinidad para obtener información del grado de “diversidad de votos” en cada noticia.

NoSQL no es la solución mágica [vídeo]

Cada vez que comento de alguna optimización el SQL de la base de datos de Menéame, en el blog o en un tweet, surgen comentarios y tweets del tipo “Cambia a NoSQL”, o “Esa estructura es especial para NoSQL”. Están muy equivocados, no es una solución óptima pra todo, ni los NoSQL están optimizados para consultas a datos estructurados. Como me da pereza escribir un apunte largo para explicarlo (que se exige más cuidado y precisión que “hablar”), grabé un vídeo (en baja calidad, para no tardar tanto subiendo, pero lo importante es la voz, no el feo que sale en pantalla).

Nota 1: En el medio de la grabación se me ocurrió poner a Instagram como ejemplo de algo que puede hacerse con bases de datos relacionales. Aunque fallé por muy poco -”se puede implementar con MySQL-, luego lo busqué y usaron PostgreSQL (con Django, la misma combinación que usamos para SpokenPic).

Nota 2:  En Menéame siempre usamos MySQL con replicación master-slave. Ahora estamos usando RDS Multi-AZ (con MySQL), lo que implica que tenemos también master-master con failover automático.

«No intentes hacer lo que no dominas»

Hoy me decidí a hacer algo que deberia haber hecho hace años, leer y aprender de diseño gráfico. No es porque me quiera dedicar a eso, o porque piense que puedo hacer cosas maravillosas, sino porque llevo muchos años trabajando codo a codo con diseñadores, con frustración de no poder resolver poblemas básicos, de tomar malas decisiones, de ni siquiera saber comunicar los problemas, o proponer soluciones.

Consejos para usuarios de programas webs

Es muy habitual que cuando un servicio introduce modificaciones en sus programas o diseño, enseguida los usuarios critican duramente hasta los aspectos más superficiales: el color es malo, el espacio no es el adecuado, no se debería haber cambiado de lugar ese botón, debería haberse usado otro icono, ese enlace debería estar arriba y no abajo, la información se debería mostrar como estaba antes, etc.

Este tipo de críticas es proporcional a la popularidad del servicio o sitio. Pero voy a explicar algnas cosas. Aunque existen numerosos casos de decisiones muy estúpidas (prefiero no dar ejemplos, algunos son amigos… o yo mismo ), la mayoría de las empresas más populares tienen programadores y arquitectos de software muy buenos, no son idiotas. O al menos, no todos, la media no es más estúpida de la media de los que escriben en blogs y Twitter. Lo que pasa es que en el desarrollo web se suelen aplicar unas pocas reglas que no suelen ser conocidas por los no programadores: