Desarrollo web: equipo y perfiles

Un amigo está pensando en iniciar un proyecto web y me he permitido hacerle un par de observaciones relativas al equipo con el que arrancarlo (también podíamos decir que está pensando en montar “un negocio en internet”, y sería preciso dado que pretende (y seguro que lo consigue) vivir de ello).

No subcontrates el equipo de desarrollo

Si te crees el proyecto, y todos damos por hecho que si te vas a meter en este embolado, te lo crees :) , no subcontrates el equipo de desarrollo. Por varias razones:

  • Te saldrá mucho más caro. Cualquier desarrollo contratado a una empresa externa, por pequeña y barata que sea, te resultará más caro que contratar a dos o tres programadores durante un año.
  • Aunque llegues a algún acuerdo y una empresa externa incluso te llegue a regalar el desarrollo (por intercambio de acciones o lo que sea), ten en cuenta que el código de un proyecto es algo vivo en lo que tendrás que trabajar de forma constante mientras dure el proyecto. Es decir, siempre vas a tener programadores manteniendo y ampliando el código. Un desarrollo empieza, pero nunca acaba.
  • Tendrás fases de más intensidad de desarrollo y otras de mantenimiento, pero siempre tendrá que haber alguien encima del código. Cuando una empresa de servicios hace un desarrollo tiene una planificación, en la que el desarrollo empieza, y el desarrollo acaba. Si se acerca la fecha de finalización o consideran que ya llevan mucho tiempo currando y que les empieza a no ser rentable, una empresa externa lo acabará como pueda, con lo que la calidad del producto disminuirá.
  • El código de alguien involucrado en el proyecto tendrá necesariamente más calidad porque ese alguien además de hacer ahora el código tendrá que convivir con él mientras trabaje en la empresa, por lo que se cuidará de que el código sea limpio, esté optimizado, ordenado, etc.
  • A la larga tendrás que tener tus propios desarrollares. Es mejor que trabajen con su propio código y no con el de alguien ajeno. Es más, cuando tengas tus propios desarrolladores hay un alto porcentaje de posibilidades de que no les guste el código y lo acaben reescribiendo.
  • El código de tu proyecto es como un niño que estás pensando en tener. A no ser que por problemas de salud no puedas tener tu propio hijo, nunca harías algo como subcontratar el embarazo y los dos primeros años de vida de tu bebe para empezar a cuidarle después, cuando “el asunto” ya esté en marcha. Lo tendrías tu y en los primeros meses es cuando le dedicarías los cuidados más especiales. Luego cuando crezca un poquito si que podrás pensar en contratar a una canguro cuando te quieras ir de cena. La web es el niño que vas a tener.

Tamaño del equipo

Siempre he trabajado con equipos pequeños y ágiles (persona ágil = proactiva, detallista, educada, optimista, con ganas de hacer cosas), y después de cierto tiempo desarrollando aplicaciones web de muy diverso tamaño, estoy bastante convencido de que no hace falta más. Es más, equipos más grandes pueden ser menos productivos.

  • Un equipo para un desarrollo de una aplicación web media (un 11870, un nvivo.es, un La Coctelera) puede estar formado para empezar por dos o tres personas. 3 programadores organizados y con las cosas claras te dan una productividad muy buena.
  • Huye de equipos en los que haya jefes de proyecto que no programen. ¿Tiene sentido un jefe de proyecto de 28 años que ha dejado la programación -o sea, que tiene poca experiencia con el código- supervisando el trabajo de un programador de 26 años sin ninguna experiencia? No tengo muy claro por qué, es una cuestión de instinto supongo, pero desconfío de una persona con perfil técnico a la que no le guste mojarse y picar código, siempre o al menos de vez en cuando, cuando su tiempo se lo permita si tiene muchas más obligaciones de gestión. Un responsable técnico que no conozca los más oscuros detalles del desarrollo no me cuadra.
  • Un coordinador o director técnico (prefiero huir del término jefe de proyecto) tiene sentido para organizar el trabajo de 5, 6, o más personas. Si no, sobra. Tres programadores (donde haya al menos uno con 10 años de experiencia, y otros dos más junior que sean brillantes) con un buen trabajo de HCI (Arquitectura de información) es más que suficiente para arrancar durante el primer año. Más adelante, cuando se empiece a crecer, pues ya podrá llegar un DBA, un sysadmin, especialistas y/o mantenedores de ciertas partes del código…

¿Qué opináis? ¿Cúal ha sido vuestra experiencia desarrollando vuestra aplicación web?

Quien la sigue la consigue, una historia de Twitter

On May 31st, 2000, I signed up with a new service called LiveJournal. I was user 4,136 which entitled me a permanent account and street cred in some alternate geeky universe which I have not yet visited. I was living in the Sunshine Biscuit Factory in Oakland California and starting a company to dispatch couriers, taxis, and emergency services from the web.

One night in July of that year I had an idea to make a more “live” LiveJournal. Real-time, up-to-date, from the road. Akin to updating your AIM status from wherever you are, and sharing it. For the next 5 years, I thought about this concept and tried to silently introduce it into my various projects. It slipped into my dispatch work. It slipped into my networks of medical devices. It slipped into an idea for a frictionless service market. It was everywhere I looked: a wonderful abstraction which was easy to implement and understand.

The 6th year; the idea has finally solidified (thanks to the massively creative environment my employer Odeo provides) and taken a novel form. We’re calling it twttr (though this original rendering calls it stat.us; I love the word.ed domains, e.g. gu.st). It’s evolved a lot in the past few months. From an excited discussion and persuasion on the South Park playground to a recently approved application for a SMS shortcode. I’m happy this idea has taken root; I hope it thrives.

Some things are worth the wait.

twttr sketch, vía Joshua.

Más tallleres en The Cocktail

Se me había olvidado comentarlo: mañana hemos montado un taller sobre expresiones regulares, a cargo del Robot, nuestro DJ-sysadmin.

Y para la semana que viene, uno de TextMate avanzado, a cargo del Dr. Naranja.

Te puedes apuntar en el wiki, como siempre.

Servicio de estadísticas para el personal media

Tenía por aquí archivados unos bocetos que hice hace dos años (de marzo de 2005… ¡da vértigo!) sobre un hipotético servicio de estadísticas orientado a usuarios con webs sencillas: blogs, páginas corporativas de pequeñas empresas, foros, etc. . El boceto es sobre el diseño de La Coctelera pero podría ser un servicio independiente.

shaker_boceto_estadisticas.png

Estaba pensando que un servicio de este tipo debería responder a dos preguntas:

  • ¿Qué contenido es el más visitado?
  • ¿De dónde viene la gente?

A partir de ahí surgirían otras cuestiones, pero creo que esos serían los ejes fundamentales. Dicho de otro modo: eso es lo que le importa a quien tiene una página personal.

¿Qué opináis? ¿Qué le pedís a un servicio de estadísticas? ¿Qué os interesa saber? (dejando a un lado paquetes complejos como Google Analytics o Nielsen)

Taller sobre APIs el 28 de marzo

Estamos preparando un taller sobre APIs en el aula The Cocktail para el día 28 de marzo. Correrá a cargo de Carlos de nvivo.es y alguien más de The Cocktail. Se hablará de cómo utilizar las APIs de MusicBrainz, Amazon, Google Maps, etc. y sobre todo, para qué utilizarlas.

En unos días daremos detalles de la hora, cómo apuntarse, etc.

Por cierto, os recomiendo una visita a nvivo.es, es una agenda colaborativa de eventos y tiene un montón de cosas que me gustaría poner en PopMadrid pero para lo que no tengo tiempo :)

Actualización: Hemos publicado el anuncio oficial, te puedes apuntar allí.

Presentaciones del Future Of Web Apps

Ya están colgadas en la web, tanto el audio en MP3 como las slides. Mis favoritas recomendadas (los enlaces están en la web):

  • La de Ben Holmes de Index Ventures, hablando sobre la financiación de proyectos.
  • Rasmus Lerdorf, el creador de PHP, por ser el creador de PHP :) (me preocupa que empiece a ser mitómano con desarrolladores de software cuando nunca lo he sido ni con estrellas de rock)
  • Khoi Vinh del NYTimes.com, grid, grid, grid.
  • Simon Willison sobre OpenID, una charla ejemplar en cuanto a estructura y contenido: fue capaz de en poquísimo tiempo explicar de forma precisa a una audiencia heterogénea un tema muy complejo.
  • Matthew Ogle de Last.fm, ya hablé de su taller, su charla fue una versión corta.
  • Stefan Fountain de Soocial, el producto no pareció gran cosa, pero el tio tenía muchísimo gancho.

Notas sobre el taller de Last.fm en el FOWA 2007

Algunas notas desordenadas tomadas el pasado jueves en el taller de Last.fm en el Future Of Web Apps de Londres. Fue un taller de tres horas el tercer día de la conferencia, titulado Scalable LAMP Development for Growing Web Apps. El taller corrió a cargo de Matt Ogle, coordinador del equipo de desarrollo de Last.fm.

  • Su servidor de BD es MySQL y la máquina donde está el maestro tiene actualmente 16 procesadores. Usan InnoDB (no dio detalles pero también, como muchos otros, odia InnoDB). Aunque dijeron que hablarían del tamaño de la BD y el esquema de replicación, al final no lo hicieron (a ver si localizo a Matt para preguntarle estas y otras cosillas).
  • Utilizan TRAC como gestor de proyecto, donde se integra el Subversion, gestión de incidencias y peticiones, etc. Además han hecho un bot de IRC que actualiza un canal de IRC interno con los commits del subversion, las actualizaciones/nuevos tickets, el despliegue de cambios en los servidores en producción y otros indicadores sobre el estado de la plataforma. También lo utilizan para pedirse las cosas unos a otros. Es lo que llaman “osmotic communication”: que toda la empresa esté al loro de lo que pasa en los diferentes rincones.
  • A raiz del interés demostrado por la gente en este bot, lo han liberado.
  • En linea con esto, utilizan metodología SCRUM para el desarrollo: basicamente consiste en iteraciones constantes con sprints relativamente cortos en vez de la planificación de grandes releases. Es decir, en vez de planear cambios radicales que duran meses planean sacar pocas funcionalidades cada dos o tres semanas. Esto lo han adoptado después de sufrir en sus propias carnes lo primero: sacar una release que se retrasa primero una semana, luego un mes, luego se sigue retrasando…
  • Otro punto interesante de esto del SCRUM es la aproximación al trabajo en equipo y las reuniones: se plantea una reunión diaria muy corta, donde se plantea a cada desarrollador tres preguntas: ¿Qué has hecho desde la última reunión SCRUM? ¿Tienes algún obstáculo? ¿Qué harás antes de la próxima reunión SCRUM?
  • People Trump Process. Hay que conseguir que el proceso no estorbe, que las cosas fluyan.
  • Utilizan Perlbal para balancear. Con un servidor con Perlbal son capaces de servir más de 4.000 peticiones/segundo hacia 25 servidores web. Diskless netboot webservers: Los servidores web no tienen la aplicación instalada en el disco duro, sino que la aplicación se despliega a memoria a través de la red (no me quedó muy claro si todo el SO está en memoria -ni siquiera si algo así es posible-). Perlbal permite modificar su configuración en caliente: puedes añadir y quitar nodos sin tener que rearrancar.
  • Utilizan Memcached y lo tienen clusterizado en todos los servidores web, de modo que tienen una Memcache de 25 GB. Su hit ratio es de más del 90%. Es decir, 9 de cada 10 consultas a la BD están en caché, y a la BD solo le llega una de cada diez. Si se añaden más máquinas al cluster de Memcache se invalida la caché, por lo que se sufre un poco hasta que vuelve a estar en caché lo más pedido. Dicen que están trabajando en una modificación para permitir el añadir máquinas sin que se invalide la caché, aunque va lento.
  • Utilizan Lighttpd para servir estáticos (imágenes del site, hojas de estilo). Y MogileFS (un sistema de ficheros distribuido y redundado) para los avatares, las portadas de discos, etc.
  • Compilan los diferentes archivos de CSS y de JS de forma automática en uno de cada para reducir el número de peticiones al servidor web y mejorar la velocidad.
  • Utilizan Rhino para comprobar errores de forma automática en el JS y comprimirlo (es Java).
  • Para monitorización Ganglia y Nagios.
  • Utilizan Hadoop (que implementa el paradigma map/reduce -the application is divided into many small fragments of work, each of which may be executed or reexecuted on any node in the cluster-) para procesar de forma distribuida y paralalela grandes cantidades de información. El ejemplo que puso fue el procesamiento de las listas semanales de los usuarios; antes de Hadoop el proceso tardaba 24 horas y con Hadoop solo 45 minutos.
  • En los primeros días de la compañía, el CEO hacía la comida para todo el mundo (hasta que fueron demasiados).

Dos conclusiones:

  • Brad Fitzpatrick de LiveJournal es el creador (y liberador!) de Memcached, Mogile y Perlbal. Se merece una posición privilegiada en el cielo de los desarrolladores web (y eso que nosotros solo utilizamos el Memcached).
  • Hay un montón de similitudes entre la forma de trabajar de Last.fm (una aplicación web graaande) y la nuestra, que estamos desarrollando una aplicación web mucho más pequeña pero que está creciendo mucho. Eso indica que estamos en el buen camino, supongo (aunque en el momento de escribir este post el site está caído…).

Lo mínimo que un maquetador web debería saber

Cualquier maquetador web, además de todo el XHTML, CSS, y JS que pueda, debería poder entender y trabajar con cosas como:

 %MINIFYHTMLb7ab2af75211e83d7c4f880f76e2c7fe9%  $localidades = popmadrid_agenda_localidades(arg(1));
  foreach($localidades as $localidad) {
    echo $localidad->name;
    $items = popmadrid_agenda_get_salas($localidad->tid); 
    if($items) { 
      foreach($items as $item) { 
	    echo l($item->title, "node/$item->nid");
      }
    }
  }

Rediseños: los usuarios dicen no

ytv.jpg Yahoo ha lanzado recientemente el rediseño de su guía de televisión, Yahoo TV. A los usuarios no les ha gustado nada. Enfatizo porque esa es la impresión que podría extraerse de los comentarios que la gente ha dejado en ese post, pero no creo que sea fidedigna.

A muchos usuarios no les habrá gustado pero es fundamental tener presente que la gente habla principalmente para quejarse. El porcentaje de feedback positivo es siempre mucho menor. Si algo no te gusta te esforzarás por encontrar un sitio donde plantear tus quejas, con la esperanza -o no- de que arreglen lo que no te gusta. En cambio si te plantan el rediseño de un site, y te gusta, estás cómodo con él, o simplemente te es indiferente, no correrás a decirlo en ningún sitio.

Si que parece que se ha empeorado la experiencia de parte de la funcionalidad esencial, la consulta de la programación – han pasado de un listado simple en HTML que cargaba rápido a algo más ajaxificado que carga no tan rápido (leyendo los comentarios de los usuarios te puedes convertir en un experto en el anterior Yahoo TV en cinco minutos).

Los cambios siempre provocan manifestaciones de reacciones negativas. Pueden provocar reacciones positivas, pero éstas se manifiestan en mucha menor medida, o no se manifiestan directamente. No hay que dejarse llevar por las críticas enfurecidas de los usuarios (porque te podrían llevar a la conclusión de que eres un diseñador pésimo, que has hecho un horrible trabajo y que probablemente no merezcas respirar el mismo aire que ellos).

La parte positiva es que tus usuarios te reportarán fallos y te proporcionarán sugerencias interesantes, y hay que estar listo para asimililarlas e integrarlas rápido.

Cuando en La Coctelera hemos introducido cambios (y eso que han sido pequeños) ha pasado exactamente lo mismo. Usuarios enfadados que no querían los cambios que habíamos hecho. Pero de los que estaban a gusto o no habían percibido los cambios, nunca supimos nada… más que siguen utilizando el servicio. Aunque los enfadados acaban cediendo en su enfado si hablas con ellos, explicas las cosas y mantienes un tono cordial.

De todos modos ahora que nos aproximamos a un cambio de diseño vamos a probarlo de forma extensiva antes de ofrecérselo a todo el mundo. Hemos montado un entorno en el que puedes utilizar la nueva versión o la antigua pero sobre los mismos datos. Se lo ofreceremos a los usuarios más activos para observar sus reacciones y aplicar los cambios pertinentes.

Muy interesante el comentario de un antiguo director de Yahoo TV:

  1. La gente odia el cambio. Hizo cientos de cambios e incluso los de más éxito solo provocaban un 5% de comentarios positivos.
  2. Felicita al equipo por haber llevado adelante el rediseño. Cuando él estaba al cargo, “parecía que Yahoo se esforzaba en dificultar cualquier cambio, en vez de apoyarlo”.
  3. El equipo ha tenido que lidiar no solo con los usuarios, sino con analistas, investigadores, la “UI police”…

Productividad en una oficina

Aaron Swartz es ese joven que con 14 años estaba escribiendo la especificación del RSS, que se cansó de su primer año en Stanford y se fue a montar Infogami (gracias al programa YCombinator), que después se juntó con Reddit y que ahora ha comprado Conde Nast para mezclarlo con Wired. Su weblog es un clásico, si eres capaz de seguir el ritmo.

En su último post habla del tiempo que te hace perder la vida en una oficina. Él, que acaba de llegar a una. Empieza a comprender por qué la gente le preguntaba que cómo conseguía ser tan productivo:

It wasn’t until I started working in an office that the question begun to make sense. Since I moved to San Francisco I literally haven’t gotten anything done. I haven’t finished a book (I finished three on the plane out here), I haven’t answered many emails (I used to answer hundreds a day), I’ve written only a couple blog posts (I used to do one a day), and I haven’t written a line of code (I used to write whole programs in the evenings). It’s a pretty incredible state of affairs.

Seguir leyendo: Office Space.

Las oficinas y el trabajo en grupo te matan. Muerte a las oficinas.

Si queremos hacer cosas diferentes y bien hechas, no puedes hacerlas en un entorno estándar y que ya se ha demuestrado ineficiente.