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.

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.

Favorecer el disenso

Este apunte tiene dos partes. El objetivo original al empezar a escribir este artículo fue describir una pequeña novedad, y sus resultados, que pusimos en marcha en Menéame el 11 de noviembre. Pero antes quería hacer una breve introducción al problema que intentamos reducir -los sesgos-, pero no me salió nada breve. Lo siento, no lo puedo evitar, pero al menos os recomiendo unos libros de lectura imprescindible si están interesado en problemas similares.

Sesgos y mala información

Está estudiado, experimentado, demostrado y ampliamente reconocido en el ambiente académico y profesional de la psicología y psiquiatría el problema de los sesgos. Éste es inevitable, nos afecta a todos, cada minuto, cada opinión y cada percepción que tenemos del mundo. Es el que nos hace ignorar la información que no se ajusta a nuestros patrones y conocimiento adquirido previamente, el que selecciona aquella información que revalida lo que pensamos (sesgo de selección) e ignora aquello que lo contradice.

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.

Novedades spokenpic

En pocas horas salgo hacia Barcelona-Zaragoza-Barcelona, así que hasta el miércoles a la noche no podré tocar nada de la app de SpokenPic. Pero en el mismo enlace que tenéis (los que lo tenéis porque nos habéis pedido, a mí o a @aaloy) tenéis una versión nueva, con muchos más controles y problema solucionados con los reportes que nos enviaron los que van probando.

El “grabador” de voz de Android tiene un problema de diseño de API importante: cada teléfono tiene diferentes modos de capturar, “samplear” y codificar, pero no todos admiten lo mismo, ni lo hacen con la misma calidad. Pero es imposible averiguar qué modos admite, ni siquiera cuál es el codificador por defecto (unos usan AAC, otros AMR, unos admiten diferentes samplings, otros no…). El de mejor calidad es el AAC, pero, por ejemplo, no todos los admiten, y en mi Samsung Galaxy Nexus da muy mala calidad, a menos que se ponga a 44.1 KHz, cosa que es imposible hacer en otros modelos. La solución temporal es que todo se pone por defecto, en algunos teléfonos genera muy buena calidad, en otros muy mala (y no tiene relación con el precio del cacharro, es independiente, por ejemplo el “barato” Sony Xperia va mucho mejor que mi Galaxy ).

Ya encontraré alguna forma de buscar la mejor solución a los modelos (debe existir, supongo). Sólo hay una mejora, en los ICS y tablets se solicita el dispositivo “VOICE”, que si existe, da más calidad de audio para voz, y mejor volumen).

Además de los controles para evitar cuelgues (la combinación de cámara y audio -de tamaños y capacidades muy variables, sobre pantallas de diferentes tamaños- en la misma “vista” es una pesadilla de programación pero ya está casi “rock solid” ). También me aseguré que cuando se cambia de aplicación todos los recursos queden liberados, así se consume menos batería y memoria (el grabador es puñetero en este sentido).

Nota: cuando se sube al web se convierte a MP3 para que el jPlayer lo reproduza en la mayoría de navegadores, eso es independiente del formato de salida del teléfono.

Actualización de SpokenPic

En el vídeo anterior mostraba (por pirmera vez) el proyecto en el que estamos embarcados, spokenpic. Después de una maratón de programación, hemos corregido bastantes bugs y la aplicación ya está casi “rock solid”. Todavía falta todo el diseño de la app (el diseño e iconos no tienen nada que con la versión beta que pubicaremos en Google Play), y bastante trabajo en el servidor, pero ya es usable. Es casi la versión “dogfood” (por “eat your own dog food”) que teniamos planificada para esta semana.

Algunos amigos ya lo están probando, podéis bajar del mismo enlace la versión que muestro en el vídeo. Los que queráis probarla (con todos los disclaimers obvios), enviadme un email (tomaros ese trabajo ), o un DM si os sigo en Twitter, os pasaré el enlace para bajar el .apk.

Gracias a los que ya la estáis probando y enviando sugerencias (insisto, la versión del web es muy de pruebas, sólo pusimos lo básico que teníamos para ir probando en público). Los requerimientos mínimos son, por ahora, Android 2.3 (Gingerbread) o superior. También funciona en las tablets (pero sólo hemos probado en dos). Por ahora asume que el teléfono tiene SDCard (interno o externo) para guadar las fotos y audios, sin él no funcionará, pero sí lo hará en pocos días.

Sobre las traducciones: la estamos programando en inglés, pero traducirlas es muy fácil (conociendo ambos idiomas), seguramente saldrá en inglés, castellano, catalán, y quizás hasta chino (una persona que lo conoce se ofreció a hacerlo, asegura que en China se usaría mucho).

El clip que hice durante el vídeo (sí, ya tengo asumido que soy más feo que pegarle a la madre).

SpokenPic: fotos relatadas

Hace un par de horas hice público en un tweet el proyecto en el que estamos metidos (con los amigos de apsl.net) hace algo menos de 2 meses. Se trata de un “scratch your own itch”, me molesta tener que escribir  para explicar una foto que quiero compartir, sobre todo cuando se está bajo el sol y no se ve bien la pantalla. Así que… mejor ver el vídeo, que me da pereza escribir

Los clips que subí durante el vídeo son este y este otro.

 

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:

Android, iOS, tiempos de respuestas y por qué nada es gratis en sistemas informáticos

Hace unas pocas horas escribí esta respuesta sobre Por qué iOS es más fluido que Android (con buen criterio, eliminaron la entrada). Obviamente, por cuestiones de longitud y la “respuesta rápida” que requiere un comentario, no me quedó todo lo completo que requiere el tema. Lo que me gustaría explicar daría para muchas horas de charlas. De hecho, enseño estos temas en mi asignatura de Sistemas Operativos (II), dedico al menos unas 12 hs de clase, y aún así no entramos en muchos detalles importantes. Pero intentaré resumirlo en este apunte, fundamentalmente para que se entiendan los problemas de arquitectura, y de cómo toda decisión que se tome en una arquitectura, lenguaje o programa tiene implicaciones positivas y negativas, siempre.

El valor de las opiniones discordantes

Desde hace años que estoy convencido que la opinión discordante muchas veces es más valiosa que la noticia, o que cientos de opiniones favorables.  Comenté unos ejemplos personales hace unos días en Google Plus, por ejemplo cómo leo las críticas en Amazon.

Cuando estoy por comprar un libro en Amazon, primero leo los comentarios que peor valoran al libro, y luego a los que mejor los valoran. Esta técnica me ayuda mucho, pocas veces me decepciona. Un ejemplo notable -porque además compré el libro sólo para verificar- es el Linchpin de Seth Godin. La distribución de los votos: