archivo

Archivos Mensuales: abril 2012

En 1986, Jobs compró Pixar por 5 millones de dolares, además de otros 5 millones de dolares que invirtió inicialmente en la misma, en total 10 millones de dolares. En 2006 Disney se hizo con Pixar pagando más de 7000 millones de dolares y convirtiendo a Jobs en el principal accionista a título individual de Disney.

Sin embargo, la aventura no resultó nada fácil, ya que Jobs ejerció de banquero principal de Pixar y la inversión inicial se multiplicó con el paso de los años. A estos hay que sumar que Pixar triunfó en el mundo de la animación (y en ello tuvo mucho que ver el software que desarrolló) pero la idea inicial era la venta de su hardware y software especializado en el tratamiento de imágenes.

Cuando todo estaba casi perdido, se llegó a un acuerdo con Disney para la realización de tres largometrajes. El éxito de Toy Story (que costó muchísimo esfuerzo sacarla adelante) y de la salida a bolsa de Pixar, crearon un cimiento muy sólido al que le siguieron éxito tras éxito.

John Lasseter fue la persona clave en este período, como lo fue Steve Wozniak en su primera etapa en Apple. Director creativo de Pixar y realizador, de su cabeza salió Toy Story y los siguientes éxitos de Pixar. Fue muy respetado por Jobs, que como artista sentía una profunda admiración por aquellos que poseían un talento superior al suyo

Lo he vivido ya en más de una ocasión y lo he sufrido no durante semanas, sino meses y en algún caso hasta años.

Poner en marcha un sistema de información en su totalidad o en gran parte sin que ningún usuario lo haya utilizado en un entorno o contexto real es una condena para el propio sistema de información y para quienes lo gestionan.

Llegarán peticiones de mejora e incidencias superiores a la capacidad que se tendrá para dar respuesta (si es que dispones de esa capacidad, ya que pocas veces se prevé que lo que se desarrolla hay que mantenerlo, de hecho los responsables o directores funcionales del sistema es lo que pensarán si no se les explica de manera adecuada y con carácter previo qué es un desarrollo de software y qué consecuencias tiene los cambios en las especificaciones sobre el coste del proyecto) y la puesta en marcha del sistema se convertirá en una cuesta arriba que no parece tener fin a la vez que no termina de aflojar su pendiente.

Es la consecuencia de la aplicación de metodologías clásicas y del efecto bola de cristal donde se piensa que todo lo definido hace meses (cuando no años) por personas que lo mismo ya no trabajan en la organización o están en otro departamento sigue siendo válido cuando se pone en marcha el sistema. Esto sucederá en la mayoría de los casos incluso habiendo realizado un análisis muy riguroso (en todo caso, la calidad del análisis reducirá los problemas, algo que, sin duda, se agradece, pero que no resuelve el problema de fondo).

Para empezar habría que definir qué se entiende cómo documentación de calidad. Para mi una documentación de calidad es un instrumento que sirve como herramienta para un desarrollo debiendo estar ajustada a las posibilidades y contexto del proyecto.

Por tanto, la documentación debe ser la precisa, ni más ni menos y por ese motivo debe ser el proyecto el que determine la que resulta necesaria. ¿Formalismos? Puedo entender que una organización quiera una homogeneidad en la documentación de los proyectos pero las normas deben ser lo suficientemente flexibles para que cumpliendo ese objetivo no sobrecarguemos a los desarrollos con exceso de documentación (más documentos de los necesarios), con excesos en cada documento (que cada documento tenga más contenidos de los necesarios) y con exceso de formalismo.

Una documentación de alta calidad no es el resultado de los formalismos que se establezcan sobre la misma sino por la adecuación de sus contenidos a los propósitos del proyecto. Tener una documentación de un proyecto perfecta a nivel formal no asegura que el producto final satisfaga las expectativas que se tenían puestas en él, lo único que asegura es la inversión de un esfuerzo que se podría haber utilizado para entregar un producto más depurado y con menor deuda técnica.

NeXT fue el reto que se marcó Jobs tras su marcha de Apple, una estación de trabajo orientada al mundo académico. Y decidió hacer lo más difícil, inventar otro ordenador, con otra arquitectura y otro sistema operativo.

Su acabado fue espectacular, su software era de vanguardia. Pero llegó tarde y no pudo encontrar un hueco en el mercado, en eso tuvo también mucho que ver el hecho de que se apostó por el desarrollo del producto pero se dejó de lado el hecho de que el éxito de este tipo de productos no solo viene dado por el acabado y la calidad técnica sino por las aplicaciones que corren sobre él.

NeXT era una máquina de perder dinero, lo que provocó que Jobs tuviera que cerrar la división de hardware y dejar de lado una de sus creencias más firmes, la cual llevó a la práctica con éxito en el pasado y fue la base en que cimentó su futuro éxito en Apple. Esa filosofía se basa en una visión holística del hardware y el software, de manera que no se puede entender el uno sin el otro a la hora de diseñarlos. Al quedarse exclusivamente con la división de software, se rompió ese binomio.

Jobs tenía un gran producto y el sistema operativo NeXTSTEP le abrió de nuevo las puertas de Apple, cuando ésta buscaba renovar el suyo.

Años más tarde la tecnología de NeXTSTEP se incorporó al sistema operativo Mac OS X.

Tim Berners-Lee usó un NeXTcube y NeXTSTEP para desarrollar el primer navegador web y comentó que el software de NeXTSTEP le ayudó y simplificó enormemente ese trabajo.

Apple compró a NeXT, si bien más pareció lo contrario, ya que poco tiempo después Jobs cogió las riendas de la compañía, puso un consejo de administración de confianza y situó en puestos de responsabilidad a algunos de los empleados más destacados de NeXT, como por ejemplo a Jon Rubinstein como responsable del área de hardware y a Avie Tevanian como responsable del área de software.

En la etapa de NeXT, Jobs aprendió a dirigir una compañía, aprendió a enfrentarse por sí solo a crisis, aprendió del fracaso, cualidades que resultaron esenciales en los éxitos conseguidos en su segunda etapa en Apple.

Por cierto, ¿alguien puede imaginar lo que sintió Jobs la mañana en que casi doce años después volvió a Apple?.

Cuando la documentación pasa de ser un medio o una herramienta a ser considerado un fin es un síntoma de que algo no marcha bien en la definición de los procesos de desarrollo.

¿Cuándo se considera un fin? Cuando las normas y procedimientos exigen de los documentos una formalidad y unos contenidos que superan las necesidades que se tienen en el proyecto y en consecuencia se produce un sobrecoste y un esfuerzo innecesario que se incrementa conforme hay que ir realizando actividades de mantenimiento de dicha documentación.

No debemos olvidar que muchos documentos por mucho formalismo y por mucho contenido que se les quiera dar son prácticamente de usar y tirar, es decir, sirven para un momento concreto del desarrollo y después terminan estando desfasados y su utilidad es prácticamente nula. Y esto en el mejor de los casos porque después hay documentos que nadie lee.

Por este motivo dos variables que se deben tener en cuenta a la hora de definir la carga documental de un proyecto o las políticas de desarrollo de software de una organización son el período de validez o vigencia del documento y su valor como herramienta de apoyo al proceso de desarrollo.

Hay una cita bastante polémica de Robert Hummel en la que comenta que: “Ordenadores más rápidos y potentes crían programadores lentos y perezosos”.

¿Que hay de cierto en esa cita?, ¿sobre qué se nos quiere advertir?.

Hago la siguiente pregunta, ¿desarrollaríamos igual si no supiéramos que la máquina en la que se va a ejecutar nuestro software tuviera muy limitada su capacidad?. Lo más seguro es que no, que trataríamos de hacer un desarrollo lo más eficientemente posible en términos de rendimiento.

Nos centramos en ejecutar trabajo, el rendimiento en ese contexto es algo secundario y dependerá el hecho de tener mejores o peores resultados de la experiencia y buenas prácticas del programador, así como del tiempo disponible para realizar la tarea.

Yo me he encontrado con casos donde no se tenía siquiera monitorizadas las máquinas de un entorno concreto de producción porque se consideraba que estaban tan sobredimensionadas que no era necesario. Mal hecho, porque después puede haber otro tipo de problemas que no se puedan detectar de manera proactiva sin esa monitorización y porque nunca hay suficientes recursos para un software mal diseñado.

A lo anterior hay que sumarle la aparición de generadores de código y frameworks que simplifican en gran medida las tareas del programador. No seré yo quien los critique, ya que creo en ellos, sin embargo hay que tener en cuenta que en muchos casos alejan al programador de los fundamentos y de las bases de la programación, tardando mucho más en adquirir una experiencia que les resultaría muy válida para ser más eficaces, a la vez que adquieren la mala costumbre de que cuando el desarrollo no puede ser tan automático su rendimiento disminuye en gran medida.

No estoy de acuerdo con Robert Hummel ya que me parece muy extrema su afirmación, si bien es cierto que en un contexto de abundancia se ponen pocos reparos a los excesos.

Las cicatrices son el framework más valioso en nuestra profesión es algo en lo que la mayoría estamos de acuerdo. Hasta que no terminas por llenarte de barro no aprendes la lección por mucho que te hayan intentado aconsejar antes.

Estamos tan convencidos de que vamos por el camino correcto que no prestamos atención a que todos los mapas indiquen que vamos en la dirección equivocada.

A veces incluso tenemos que caer varias veces en el mismo charco para terminar de darnos cuenta de que nos estamos mojando.

Pero el conocimiento se encuentra ahí, en descubrir qué hemos hecho mal y por qué, debiéndose analizar también el contexto en el que hemos actuado. No es posible realizar un buen análisis y obtener unas conclusiones adecuadas sin analizar en qué entorno o contexto hemos realizado nuestro trabajo, tal vez el problema no se encuentra en haber actuado de una determinada forma sino en haberlas puesto en práctica en un contexto que no era el adecuado.

Jim Horning tiene una cita que resume perfectamente el papel de la experiencia y de los fracasos en nuestro desarrollo personal y profesional: “El buen juicio proviene de la experiencia. La experiencia proviene del mal juicio”.