Mes: septiembre 2006

Sin duda este no es un libro típico de informática. Un libro cuyo principal proposito es cambiar la manera en la que los desarrolladores utilizan el pensamiento, su principal herramienta de trabajo cuando desarrollan software, no puede ser un libro típico. Exponer los objetos como la entidad mínima de pensamiento cuando desarrollamos software, hacer de los objetos el elmento central del proceso creativo de desarrollar software y plantear el descubrimiento de la solución informática que el cliente necesita como la búsqueda de los objetos que solucionan el problema es sin duda algo novedoso que va más allá de la visión tradicional de los objetos como datos más metodos. David Wast pretende que todo es un objeto y que el desarrollador debe 'pensar en objetos', nos da los razonamientos de por que esto es util, que a mi me han convencido, y nos guía en el proceso de convertirnos en 'pensadores en objetos', dejando claro que este no es un proceso escrito en piedra sino algo que cada desarrollador debe interiorizar.

Cabe plantearse la prengunta de si el libro logra su proposito. ¿Realmente este libro cambiará cómo sus lectores se enfrentan al desarrollo de software utilizando objetos? Sin duda, lo logra. Pero en que grado, depende de la experiencia que el lector tenga desarrollando software usando técnicas orientadas a objetos. El desarrollador que lleve cierto tiempo usando objetos no va a cambiar radicalmente como realiza su trabajo, pues probablemente ya este poniendo en práctica gran catidad de las ideas expuestas en el libro bien explicita o implicitamente. Esto no quiere decir que el libro no sea de valor para el desarrollador senior. Sin duda leer cual es el mecanismo que no lleva a pensar en objetos nos va a ayudar a refinar y mejorar como realizamos ese proceso y a hacernos idea clara de cuan importante es. El desarrollador junior, o alquel que ha llegado recientemente al mundo de los objetos sin duda debe leer este libro si quiere comprender que son los objetos en su más pura esencia y como nos ayudan a resolver los complejos problemas que el software trata de resolver mediante la resolución de pequeñas partes finitas del problema en que cada uno de los objetos que componen el sistema es especialista.

El libro es también peculiar en el sentido de relacionar la informática, en concreto el desarrollo orientado a objetos, con ciencias que en cierto modo le son ajenas como la historia ola antropología, lo que hace que el libro cuente con pasajes muy amenos. Me parece especialmente interesante el paralelismo entre el trabajo del analísta cuando trata de descubrir los objetos de un determinado dominio y el del antropólogo que trata de desentrañar lo entresijos de la cultura que estudia.

En ciertos captitulos el libro parece el resultado de reunir a todos los padres del software orientado a objetos en torno a unas cervezas y destilar los conocimientos y la filosofía que les llevo a iniciar la revolución que supuso la apareción de los objetos en el desarrollo de software. Tambien puede dar la sensación en algunos pasajes, que el autor David West se ha pasado un poquito con las cervezas ;). Lo que menos me gusta es el incapie que me parece en cierto modo forzado de tratar de relacionar el pensamiento orientado a objetos con eXtreme Programming, sugiriendo incluso que solo usando XP se puede llegar a 'pensar en objetos'.

Dicho esto que nadie piense que el libro solo trata aspectos 'filosóficos' y no técnicos. Compartamos o no la filosofía que el autor defiende, el libro es de gran utilidad pues presenta técnicas efectivas para conceptualizar y modelar sistemas de objetos para descubrir los objetos que componen el dominio de la aplicación e identificar las relaciones entre los objetos, los dos principales problemas a los que nos enfrentamos cuando hacemos análisis orientado a objetos.

En resumen, el libro merece la pena, compartamos o no los aspectos más 'filosóficos' del mismo, pero según en que medida nos cale la visión del autor el libro nos parecera mejor o peor. Es probable que si prefieres Srcum a CMMI, el libro te guste. No hay recetas en este libro, los buenos conocineros no se hacen utilizando recetas de otros, sino más bien mediante trucos, conocimientos, observación y asimilación del trabajo de los grandes maestros. En cieto modo es lo que este libro nos ofrece, ver cual es el proceso creativo que se esconde en la cabeza de los grandes pensadores del 'pensamiento orientado a objetos'.

Me escribía, hace unos días, uno de los asistentes a la ponencia sobre Calidad del Software y Team System que impartí en los Cursos de Verano de la UPNA. Me comentaba que lo visto en mi ponencia le había causado muy buena impresión y que había decido poner en práctica algunas de las técnicas y herramientas allí comentadas. El problema que se le presentaba, es que en su empresa, un pequeño ISV, sus jefes no percibian la calidad como algo importante, es más importante para ellos tener un mayor número de características que un software de mayor calidad. El razonamiento es simple, la calidad no se puede poner en un anuncio o en una oferta. Esta mentalidad podría ser razonable para muchos productos, pero no lo es para el software. Trataré de explicar el por qué.

Si tu produces, por poner algo simple, bolígrafos, puedes decidir que tu segmento del mercado es el de los bolígrafos baratos, de baja calidad. Y sin duda te puede ir muy bien, no todo el mundo necesita un pluma Du Pont, para firmar su hipoteca. Tendrás un motón de clientes que solo ven en el momento de la compra de un bolígrafo su precio, y que además en el momento de la compra no van a evaluarlo a fondo. Además, reducir la calidad, en el caso de la gran mayoría de los productos manufacturados, tiene el efecto directo de abaratar los costos de producción. Muchos de los directivos actualmente al mando de empresas que construyen software han sido formados en sectores ajenos a la informática, una industria muy nueva, y a menudo caen en el error de pensar en la producción de software desde los parámetros habituales en otras industrias. Este es un error habitual, la producción de software es muy diferente, es un proceso creativo no un proceso manufacturero.

La principal diferencia cuando 'fabricamos' software es que la calidad no es opcional, no puedes elegir fabricar software de baja calidad y rebajar el precio. Ese enfoque no funciona por varios motivos:
 
Primero: Puedes hacer bolígrafos de baja calidad que hagan su labor aceptablemente, pero no puedes hacer software de baja calidad que funcione y cumpla su misión aceptablemente. Además, los usuario cada vez son menos tolerantes con los errores en las aplicaciones. Pensemos en como ha evolucionado la calidad del software que todos tenemos en común, el sistema operativo. Todos recordamos la pantallas azules de la muerte de Windows NT, alguna vimos en 2000 y luego llego Windows XP y la mejora fue notable. Lo mismo a ocurrido en otros sistemas operativos, como Linux, donde cada vez es más dificil ver un Kernel Panic. Al ser el sistema operativo el software que todos usamos, es el que se combierte en patrón de calidad. Con Windows 95 no era importante que nuestros programas 'cascasen' con cierta frecuencia, el usuario estaba acostumbrado a que el sistema operativo fallase y era más o menos permisivos con nuestros fallos. Con la mejora de la calidad de los sistema operativo el usuario esta subiendo el listón de la calidad y si queremos seguir vendiendo nuestro software más que el de la competencia la calidad del mismo se esta convirtiendo en un factor vital.

Segundo: Antes de comprar un software o contratatar la realización software con una compañia de desarrollo, el usuario compara a fondo. Y a menudo el precio no es el factor principal. Nunca venderemos un software si el instaldor de nuestra demo falla con solo ejecutarlo con un usuario que no es administrador, por barato que sea, el usuario no se va a tomar un segundo más en seguir evaluando nuestro software. Ni venderemos un proyecto de desarrollo si a los oidos del comprador llega una mala experiencia de una empresa que nos contrato con anterioridad, por economica que sea nuestra oferta. Solo centradonos en la calidad lograremos evitar este tipo de problemas. Nadie recuerda quien hizo un buen software, pero nadie olvida que hizo uno que no funciona correctamente porque lo sufre a diario.

Tercero: Quiza el factor más importante y menos evidente es que añadir calidad a nuestro software, al contrario de lo que puede parecer a primera vista, reduce los costes de desarrollo y acorta los plazos. La reducción de costes se produce porque con un adecuado proceso de desarrollo, que tenga la calidad del software como un factor central, se descubre antes los errores. Y los errores, de cualquier indole, son más costosos cuanto más tarde se descubren, además estos coste se incrementan siguendo un función exponencial. Descubir que nuestra arquitectura no es capaz de gestionar el número requerido de transacciones por segundo, es infinitamente más costoso de corregir si se descubre durante las pruebas de aceptación que durante la revisión de la arquitectura. La reducción del tiempo de desarrollo se produce porque es mucho más facil construir software sobre software estable que sobre software que no es estable. Hoy en día todos los procesos de desarrollo de software son en mayor o menor medida iterativos e incrementales. Es imposible construir un incremento de funcionalidad si la base de ese incremento no es estable.

Dicho esto, es curioso ver las situaciones paradójicas que se dan en cuanto a la calidad en los proyectos y las empresas de desarrollo de software. He visitado empresas, generalmente para impartir formación, con grandes carteles en recepción del estilo "La calidad es nuestra esencia" o "La calida al servicio del cliente" y con todas las certificaciones habidas y de por haber de 'calidad' que no tienen ni un solo especialista en calidad del software, ni un solo especialista en probar aplicaciones. ¿Se imaginan una empresa de industrial, que se tome en serio el mantenimiento de sus maquinas, sin un solo experto en mantenimiento?, pues esto es la norma en las empresas de desarrollo, dicen preocuparse por la calidad pero no cuentan con un solo experto en el tema. Y no, lo desarrolladores, no son expertos en calidad y pruebas. Pero este es otro tema, que sin duda abordaré en el futuro. ¿Por qué se dan estas paradojas en el desarrollo de software?.