29 junio 2007

Un coche arrastrando un avión

El anuncio del Volkswagen Touareg arrastrando un avión Boeing 747 impresiona. Si no lo has visto, lo tienes (por ejemplo) aquí:

http://www.youtube.com/watch?v=kPC8-7l9Esg

¿Puede realmente un coche "de serie" mover un avión? He estado buscando información y parece ser que sí (con algún "pero"). En un artículo de Serious Wheels detallan (en inglés) los preparativos y el proceso.

Pero claro, se trata de un coche "casi de serie"... con 310 caballos de potencia, con un precio cercano a los 60.000 dólares (*), no es "un coche normal". Es el modelo equipado con motor V10 TDI, al que se hicieron apenas unas mínimas modificaciones. Además, se cargó con 4.345 kg extra para asegurar una mejor tracción en el momento de la arrancada (una vez que se ha comenzado a andar, mantener el movimiento no es problema).

En cuanto al "objeto a mover", es un avión de 155 toneladas de peso, 4 motores, un fuselaje del tamaño de un bloque de pisos, 450 asientos, una superficie alada de 511 m2...

Si quieres ver un video un poco más detallado (5 minutos, en inglés), aunque también algo propagandístico:

http://www.youtube.com/watch?v=9sO_xmXiQqM

(*) En cuanto al precio en España, en una primera búsqueda no he encontrado precio oficial para el V10 TDI, pero el FSI de 280 caballos anda entre 52.000 y 56.000 euros, según versiones, y el 4.2 V8 salta de los 70.000 euros. Como siempre, los coches nos resultan más caros en Europa que en Estados Unidos... incluso los de origen europeo.

22 junio 2007

Uno es el número más solitario

En la programación, el Uno es el número más solitario

(Traducción de In Programming, One Is The Loneliest Number, original de Jeff Atwood, en su blog "Coding Horror". Traducido con permiso.)

----

¿Es el desarrollo del software una actividad preferida por personas misántropas, antisociales, que preferirían a los ordenadores antes que al resto de la gente?

¿Si es así, entonces se puede suponer que todos los proyectos software los realiza mejor una única persona, trabajando en solitario?

La respuesta a la primera pregunta puede ser un sí dudoso, pero la respuesta a la segunda pregunta es un contundente No. Me impactó definitivamente este artículo maravillosamente escrito que explica los peligros de la programación en solitario:

  • Hay gente que dice que [trabajar solo] supone una gran oportunidad de establecer su propio proceso. En mi experiencia, no existe proceso en un equipo de uno. No hay nada que permita frenar los aluviones del trabajo que vienen en cualquier momento. No hay nadie para corregirte cuando llegan las prisas por avanzar código como si buscaras una medalla de oro. No hay nadie para repasar tu código. No hay nadie para asegurarse de que tu código es comprobado a tiempo, documentado correctamente, de que las unidades se prueban regularmente. No hay nadie para asegurarse de que estás siguiendo un estándar de codificación. No hay nadie para supervisar tu puntualidad en la corrección de defectos. No hay nadie para verificar si estás marcando defectos como "no reproducibles" cuando realmente sí lo son. No hay nadie para comprobar tus estimaciones con minuciosidad, que te avise cuando te las estás sacando de ninguna parte.

  • No hay nadie que pueda dedicar un tiempo extra cuando estás enfermo, o lejos en viaje de negocios. Nadie te puede echar una mano cuando estás con exceso de trabajo, saturado con llamadas telefónicas, reuniones insustanciales, y las tareas de poca relevancia que alguien te suelta a última hora y deben ser hechas justo en ese momento. No hay nadie de quien recibir ideas, nadie que te ayude a salir cuando no se te ocurre algo, nadie para colaborar en los diseños, las arquitecturas o las tecnologías. Estás trabajando en un vacío. Y en el vacío, nadie puede oírte gritar.

  • Si estás leyendo este texto, deja que te sirva de lección. Piénsalo seriamente antes de aceptar un trabajo como único desarrollador en una compañía. Es una clase totalmente nueva de infierno. Si se te da la ocasión, elige un trabajo con otros desarrolladores, donde al menos puedas trabajar con otros que te puedan tutelar y ayudarte a desarrollar tu habilidades, y te mantengan al corriente de la tecnología actual.

El trabajo en solitario es una tentación para muchos desarrolladores de software desesperados que se sientan atrapados, rodeados por la incompetencia y la mala gestión en el desierto de lo real. Trabajar en solitario supone control total sobre un proyecto del software, teniendo poder total sobre cada decisión. Pero trabajar en todas las partes de un proyecto de software por ti mismo, en vez de potenciarte, resulta paradójicamente debilitante. Es un espejismo que se mueve y ofrece la torturadora promesa de poder llegar más allá, mientras que de alguna manera te va dejando más sediento y más débil que cuando comenzaste.

Como muchos programadores, me interesaron a las computadoras cuando era niño porque era introvertido. El mundo de las computadoras -- ese tranquilo, racional oasis de unos y ceros -- parecía mucho más sugerente que el mundo irracional, inexplicable de la gente y las interacciones sociales, en las que no está claro qué es correcto y qué no lo es. No es que las computadoras fueran mejores que la gente, sino que eran mucho más fáciles de entender.

La informática, en las primeras épocas antes de Internet era por definición una actividad solitaria. Dani Berry, el autor de M.U.L.E., resume con esta famosa frase: "nadie ha dicho nunca en su lecho de muerte, 'Vaya, desearía haber pasado más tiempo a solas con mi computadora.'" Pero ha pasado mucho tiempo desde los días de la programación de 8 bit en solitario. Internet, y el creciente alcance y complejidad del software, lo han confirmado. Actualmente apenas puedo programar sin una conexión de Internet activa, me siento lisiado cuando no estoy en red con la extensa colmena mental del conocimiento de programación en Internet.

¿De qué sirven unas espectaculares habilidades de programación si no puedes demostrarselo a nadie? ¿Cómo puedes aprender el arte sin comunicarte con otros programadores con distintas ideas, distintos intereses, y distintas habilidades? ¿Quién repasará tu código y te dirá cuando hay una aproximación más fácil que tú no has visto? Si te tomas en serio la programación, deberías exigir trabajar con tus semejantes.

Ahora puedes entrar en este campo por ti mismo. Busca otros programadores eficientes. Trabaja con ellos. Esfuérzate por ser el individuo más callado de la habitación, y descubrirás rápidamente que el desarrollo del software es una actividad mucho más social de lo que la mayoría de la gente se da cuenta. Hay mucho que puedes aprender de tus introvertidos compañeros.

----

Como viene siendo habitual, estoy de acuerdo con Jeff.

Aun así, no todos los que añaden algún comentario al blog lo están también. Por ejemplo, hay quien da argumentos a favor del trabajo en solitario, como éstos:

  • Propiedad total de las decisiones del diseño.
  • Ser responsable de la agenda del proyecto.
  • Poder fijar tus propias prioridades, sin necesitar alentar a otros a que vivan por ellas
  • No necesitar actuar de "niñera" de desarrolladores menos experimentados
  • Poder utilizar un proyecto para explorar una nueva tecnología, sin tener que justificar la decisión a otros miembros del equipo o a encargados de proyecto
  • Poder comunicarse directamente con los clientes sin tener que trabajar a través de intermediarios (como encargados de proyecto o analistas).
  • No hay que ocuparse de código heredado de otros desarrolladores; como todo el código es el mío, mi familiaridad es mayor.
  • Poder elegir qué lenguaje y qué base de datos utilizar para los nuevos proyectos.
  • No tener que perder ni una hora en reuniones del equipo ni con los encargados

Tiene también su parte de razón, pero en general, en cualquier proyecto que no sea muy pequeño, es casi imprescindible trabajar en grupo, aun sabiendo que supondrá costes de comunicación y que las decisiones deberán aprobarse entre todos (o al menos por mayoría). Y en cualquier caso, trabajar con otros programadores puede ser una experiencia muy enriquecedora.

Personalmente, yo soy más partidario de la programación en pequeños grupos que del trabajo en solitario. Me gustan la mayoría de las ideas de la "programación extrema" (XP): programar en parejas (en las que sólo uno está tecleando y se intercambian los papeles cada cierto tiempo), crear las pruebas antes que el código, interacción frecuente con el usuario...

Si aún no has probado a programar en grupo, júntate con 2 o 4 amigos y haced un videojuego sencillo (por ejemplo). Puede salir algo interesante, puedes aprender de ellos y ellos pueden aprender de ti. Si escoges bien el grupo, descubrirás que programar en grupo puede ser mucho más motivador que en solitario. Suerte!!!