Archivo
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.
La evolución de acceso móvil de los lectores, y los medios online
Estas son estadísticas de sistemas operativos en Menéame, mirad los porcentajes de cada sistema operativo:
Hace dos años:
Hace un año:
Hace seis meses:
Ahora:
El último fin de semana:
Conclusión: Android es el segundo sistema operativo, iOS es el tercero. Por encima de Mac y GNU/Linux. Android e iOS representan el 30% de las visitas. La inmensa mayoría del crecimiento se dio en los últimos dos años.
¿Cómo están los medios adaptándose a este cambio tan radical de la forma de acceder a las noticias?
Por las capturas de algunos de ellos (en un Galaxy Nexus, tomadas casi al azar, de las últimas 3 páginas de portadas de Menéame), veréis que en general muy mal. Sólo tres tenían una versión optimizada para móviles. Los demás es la misma versión web, que obliga a hacer zoom en la pantalla, a veces con pésimos resultados. Y en la mayoría la página tarda eones en cargar, especialmente por la publicidad. En otros incluso te aparece un intersticial con el botón de cerrar tan pequeño y tan en el borde, que es casi tarea imposible.
Todos nos haríamos un favor si se molesta menos al usuario, a veces basta con ocultar una columna con el CSS, y/o quitar una parte de la publicidad.
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.
“Lo que demanda el mercado”, y el conservadurismo en la universidad
El lunes fui a Dublín para unas entrevistas en Google. Apenas llegué al hotel abrí el siguiente email, Amazon buscando desesperadamente (ya lo hacen en grupos abiertos, no sólo por recruiters) ingenieros expertos en GNU/Linux para Dublín. Sumado a que justamente estaba por ir a Google, que también exige (o da mucha importancia) a los conocimientos de Linux, inmediatamente me acordé los años de luchas y problemas en la universidad para poder enseñar sobre GNU/Linux.
Empecé a dar las asignaturas de sistemas operativos en el curso 1993-1994, los primeros dos con Minix (sólo teníamos Macs Performa, y adapté el kernel MacMinix para que funcione en ellas). Luego quitaron los Mac, pusieron PCs con Windows NT y no me dejaron instalar Linux. Tuve que dar un curso con las prácticas con Cygwin sobre esos Windows, o vía telnet al VAX VMS con los alumnos. El primero pasable -aunque doloroso-, el segundo infumable. El C del VMS era muy poco compatible en temas de llamadas de sistemas, y cada clase de viernes a la tarde se colgaba, o fallaba con tantos usuarios.
El espejismo de las patentes como medidor de calidad de la investigación
Hoy leo en El País El archipiélago universitario, dice muchas cosas con la que estoy de acuerdo, pero comienza con la siguiente frase (con los números muy equivocados):
En 2010, el sistema universitario público español obtuvo 401 patentes. Robert Samuel Langer, un investigador químico del Massachusetts Institute of Technology (MIT), él solo, tiene 810, más del doble.
Desde hace varios años se insisten con estos argumentos, como si las patentes fuesen un medidor válido de la calidad de la investigación. En términos generales no lo es, y menos cuando se trata de medir investigación, la “I” de I+D.
A los que se cachondean del inglés de los demás
A los que se cachondean del inglés de los demás
Iba a escribir algo muy corto y me salió más largo de lo pensado, si no lo hubiese puesto como apnte aquí. Estoy bastante molesto por cómo se ríen de los que hacen el esfuerzo de hablar inglés en público. Hoy es Ana Botella, pero ayer fueron otros. Un mensaje de burla y castigo al que se esfuerza por superar sus limitaciones.
Guía gráfica básica de fiabilidad de tendencias para periodistas y politólogos
Muchas veces os llegan gráficos de tendencias, que está subiendo o que está bajando, y no sabéis qué grado de fiabilidad tienen esas tendencias. Aquí dos ejemplos gráficos simples.
Es fiable esa tendencia
“Ley Lassalle”, ni la economía lo justifica (tampoco a la Sinde-Wert)
Para no agobiar con los números, el siguiente gráfico comparativo de volúmenes de negocio por industrias, en millones de euros:
Después de dos años de mucha genta contra la Ley Sinde/Wert dos años, explicando que no funcionaría, el PP la aprueba. Un año después, verificado el fracaso, pretenden modificar la LPI con lo que conocemos como “Ley Lasalle”. Otra vez insisten en “proteger” a un sector industrial (¿cultural?). Este nuevo borrador, de nuevo, entra en conflicto con derechos fundamentales (privacidad de comunicaciones, derecho a defensa, juicio justo) y seguramente producirá efectos negativos en los negocios digitales básicos (como explica Julio Alonso en Diario Turing).
El borrador de la nueva LPI no mejora derechos fundamentales, chirría con ellos.
Tampoco crea o amplía derechos individuales, los reduce.
Su única justificación es la de “mejorar la economía de una industria”, en detrimento de otras.
Como ejercicio intelectual simple, ubique en el gráfico a qué industrias podría favorecer, a cuáles podría perjudicar, y el volumen de negocio (y capacidad de generar empleo) de cada una de ellas. Si encuentra la justificación, me lo cuenta.
Fuentes de cifras
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).
Comentarios recientes