Gigantes investigando: un vistazo al futuro

Creo que por acá todos saben que las empresas más grandes en la industria del software no paran de investigar, a ver quién gana en el próximo salto tecnológico, o quien se asegura un par de patentes que les de ventaja en el mercado los próximos años.

Más allá de que estemos de acuerdo o no con la política alrededor de la propiedad intelectual, es interesante echar una mirada a lo que están haciendo algunos de los principales centros de investigación de los gigantes de la industria. Gracias a la gente de Y Combinator, les dejo una serie de links a las páginas principales  sobre el tema:

• Microsoft Research y sus publicaciones
  Sus áreas de investigación cubren Comunicaciones y colaboración, Lingüistica computacional, Ciencias de la computación, Sistemas y Redes, Economía y Computación, Educación, Juegos, Gráficos y Multimedia, Hardware y Dispositivos, Salud y Bienestar, Interacción entre Computadoras y Humanos, Recuperación y Administración de Información, Aprendizaje Mecánico, Seguridad y Provacidad, Ciencias Sociales, Desarrollo de Software, Teoría y otras áreas temáticas.
   
• Research at Google y sus publicaciones
  Cubren Algoritmos y Teoría, Inteligencia Artificial y Aprendizaje Mecánico, Administración de Datos, Minería de Datos, Sistemas Distribuidos y Computación Paralela, Economía y Comercio Electrónico, Innovación en Educación, Ciencia General, Hardware y Arquitectura, Interacción entre Humanos y Computadoras y Visualización, Recuperación de Información y la Web, Percepción Mecánica, Traducción Mecánica, Sistemas Móviles, Procesamiento de Lenguaje Natural, Redes, Seguridad, Criptografía y Privacidad, Ingeniería de Software, Sistemas de Software y Procesamiento del Habla.
  
  
• IBM Research y sus publicaciones
  Uno de los pioneros en investigación de todo tipo, con más de 60 años en el tema y varios premios nobel a cuestas, cubren de todo, desde exploración y control espacial, genética y genómica, láseres industriales y quirúrgicos, salud, minería y por supuesto casi todas las áreas de software y hardware.
   
• Yahoo! Labs y sus publicaciones
  El menor de la serie, tal vez por ser la empresa que tiene hoy más problemas de crecimiento y subsistencia, de todas maneras se mantiene activa en áreas como Publicidad Computacional, Interacción entre Humanos y Computadoras, Medios, Aprendizaje Mecánico, Movilidad, Personalización, Investigación de Sistemas, y Búsqueda y Minería Web.

Les dejo un par de videos sobre los dos primeros, para darse una idea del estilo.

Research at Google (~3 min):

  

y un Tour por Microsoft Research (~10 min):

Imperdible: cócteles para programadores

Todos los años se festeja el Día del Programador, el día número 256 del año. Esta vez pasó el 13 de septiembre, y para festejarlo, un colega ruso publicó una serie de cócteles para programadores, publicada en GitHub, traducida a varios lenguajes, incluido el español, y con varias fotos muy buenas, algunas de las que reproduzco a continuación para abrirles el apetito (o la sed, en este caso).

Gracias a los amigos de Surculus Fructum por el dato.

Debajo, los cócteles para Ruby, Python y Assembler, respectivamente. En el post hay varios más, incluyendo las recetas. ¡Salud!

  

Agile Solo: Manejando el backlog personal

Continuando con la serie Agile Solo, hoy quería comentar algunas ideas para manejar el backlog de tareas y mejorar el nivel de compromiso de uno mismo hacia sus clientes o usuarios.

Una buena práctica para no dejarse tentar por la procrastinación es utilizar alguna herramienta para hacer público nuestro backlog. Como siempre, desde la agilidad le damos prioridad a la interacción entre las personas, por lo que prefiero concentrarme en cómo me comunico, y usar las herramientas más sencillas posibles (en particular me gusta Trello por que es liviano y su funcionalidad es mínima).

Lo importante para mi del backlog es tener donde volcar las clásicas tres columnas: pendiente, en marcha y terminado. Y lo bueno de tener una manera de hacerlo público es que podemos mostrar a las personas involucradas qué planificamos (por ejemplo, para la semana) y cómo vamos. Es posible que tengamos que unificar temas de varios clientes, y puede haber algunos relativamente confidenciales, para lo que prefiero usar nombres de código para los proyectos. De esta manera, cada cliente sabe el nombre de código, y puedo usarlo como “etiqueta” en mi backlog, sin divulgar identidades, preservando su confidencialidad. De la misma manera, no necesito poner detalles demasiado específicos de la tarea pendiente; alcanza con que ponga algo que mi cliente comprenda. Veamos un ejemplo:

Algunos tips sobre los nombre de código que me resultan útiles:

• No hacen falta para cosas no-confidenciales (en mi ejemplo, C&B para este blog, MUG, nombres de amigos)
• Conviene usar nombres que no signifiquen nada y que no tengan ninguna connotación. 
• Es bueno tener a mano una serie de muchos nombres disponibles. Yo elijo, por ejemplo, nombres astronómicos (estrellas, planetas o satélites) porque hay miles y usualmente no acarrean ningún significado especial. En otros casos utilicé nombres de ríos, pájaros, flores o plantas, frutas, etc. Google utiliza nombres de dulces para Android, Ubuntu animales más un adjetivo, etc.
• Lo importante es que el cliente reconozca SU proyecto (en el ejemplo, Fobos y Deimos son proyectos de clientes diferentes).

Obviamente exponer nuestro backlog plantea desafíos, pero yo creo que son sanos. Por ejemplo, el cliente de mi proyecto Fobos podría reclamarme prioridad sobre Deimos, aunque no sepa quien es. Eso nos obliga a ser transparentes, pero también a poder explicar racionalmente nuestra priorización, y el problema se termina si al final de cada iteración todos están conformes. También, aunque no hayan gran nivel de detalle en cada item del backlog, lo que hacemos para un proyecto puede inspirar ideas a otros clientes, y no está mal que esto pase.

Hay otras alternativas, por supuesto, como tener backlogs separados por cliente, donde cada uno vea su parte. En mi experiencia esto nos complica más de lo que nos ayuda, porque oculta la complejidad de nuestras actividades, y hace sentir a cada cliente que trabajamos solamente para él (lo que no está mal si es real).

Como siempre, hay cosas que dependen del nivel de madurez, pero en general yo prefiero que quien actúa de Product Owner en mi cliente tenga acceso a mi backlog y pueda poner todo lo que quiera. ¿Me arriesgo a que cambien prioridades? Si, pero prefiero siempre brindar más libertad y pedir responsabilidad que tratar de controlar. :)

Espero que algunas de estas ideas sirvan aunque sea para cuestionarlas y generar prácticas alternativas.