Tag Archive | libros

Agile principles, patterns and practices in C#

Agile principles, patterns and practices in C#

Robert C. Martin

Por qué lo he leído

Lo he leido porque me he encontrado referencias a este libro en libros anteriores que he leído, en blogs sobre desarrollo de software que suelo leer y en otros muchos sitios relacionados con el software. Si encuentro tantas referencias, será por algo, ¿no? Además, el autor es muy conocido y valorado, así que no había excusa para no leerlo.

Qué esperaba

Me esperaba un libro de Uncle Bob™. Ya he leído alguno del mismo autor, y me gusta su estilo. Algunas veces me parece un poco extremista, pero creo que es así porque cree en lo que hace y eso es lo que predica. Cuando creo que exagera, no le hago mucho caso y sigo hacia adelante, ya está.

Esperaba una descripción de las metodologías ágiles aplicadas al momento de escribir software y encontré …

Qué encontré

… un pedazo de ladrillo! Me asusté cuando vi la extensión del libro, pero enseguida entendí el porqué. El libro está lleno de diagramas UML y de código fuente (primero los tests, por supuesto). Así que es normal que sea tan largo.

En cuanto al contenido, me gustó mucho la descripción que hace de muchos patrones de diseño, (incluso he aprendido alguno que no conocía). En el libro también podrás encontrar una descripción detallada de los principios SOLID y de otros principios sobre cómo organizar y empaquetar los distintos componentes de tu aplicación (clases, paquetes, namespaces, lo que sea).

Conclusiones

Aunque el libro sea muy extenso, me ha gustado por varias razones:

  • He aprendido nuevos patrones de diseño.
  • He podido profundizar sobre el patrón Model-View-Controller (ver enlaces más abajo).
  • He encontrado una descripción muy detallada de los principios SOLID.

Pasajes que quiero recordar de este libro

Un módulo que es difícil de cambiar, está roto y necesita ser arreglado, aunque funcione.

Un módulo que no comunica está roto y necesita ser arreglado.

Cuanto más conocen los programadores sobre todo el proyecto, más sano y más informado está el equipo que lo desarrolla.

Es el big picture lo que mantiene unido el sistema. Es la visión del sistema lo que hace obvia la localización y la forma de los módulos individuales. Si la forma de un módulo es inconsistente con la metáfora, es el módulo quien está mal, no la metáfora.

Al final, el código fuente es el diseño.

Se sabe que el software se está pudriendo cuando empieza a mostrar alguno de los siguientes síntomas: rigidez, fragilidad, inmovilidad, viscosidad, complejidad innecesaria, repetición innecesaria u opacidad.

El elemento más volatil en los proyectos software son los requisitos. Vivimos en un mundo de requisitos cambiantes, y nuestro trabajo es estar seguros de que nuestros software puede sobrevivir a esos cambios, así que no culpes a los requisitos cambiantes por los fallos en el software.

Los principios SOLID: Single responsability principle, Open close principle, Liskov substitution principle, Interface segregation principle, Dependency inversion principle.

Un motivo de cambio es un motivo de cambio sólo cuando el cambio ocurre, mientras tanto no.

Strategy and Template method son las formas más comunes de satisfacer Open closed principle. Estos patrones representan una clara separación de la funcionalidad genérica de la implementación detallada de esa funcionalidad.

Fool me once, shame on you. Fool me twice, shame on me. Inicialmente, escribimos nuestro código pensando que no va a cambiar. Cuando ocurre un cambio, implementamos abstraciones que nos protegen de futuros cambios de esa misma naturaleza.

Liskov substitution principle nos lleva a una importante conclusión: un modelo, visto aisladamente, no puede ser validado significativamente. La validez de un modelo puede ser expresado solo en términos de sus clientes.

Liskov substitution principle clarifica que en la programación orientada a objetos, una relación de herencia pertenece al comportamiento que puede ser asumido y que los clientes dependen de este comportamiento, lo contrario de lo que normalmente se cree, que la herencia pertenece al estado

El diseño de grandes sistemas depende críticamente de un buen diseño de componentes (paquetes, entregables, …), de esta forma, los equipos individuales puede enfocarse en componentes aislados en lugar de preocuparse por el sistema completo.

Las interfaces pertenecen al cliente que las usa, no a la implementación. El enlace lógico entre el cliente y el interfaz es más fuerte que la relación entre el interfaz y sus implementaciones. Es tan fuerte que no tiene sentido desplegar el cliente sin el interfaz, pero sí que lo tiene desplegar el interfaz sin sus implementaciones.

Otras lecturas y enlaces relacionadas

Anuncios

En el principio… fue la línea de comandos

En el principio… fue la línea de comandos

Neal Stephenson

Por qué lo he leído

Había oído hablar de este libro en la universidad, y me picó la curiosidad, pero nunca me había decidido a encontrarlo y leerlo. Pero hace poco, viendo uno de los hangouts de Desarrollo Web, lo comentaron y no perdí ni un minuto. Lo descargué y a leer se ha dicho.

Qué esperaba

No recuerdo muy bien qué esperaba. Siempre había oído hablar de este libro en contextos de sistemas operativos, ordenadores antiguos. Temas más bien históricos. Así que, lo que esperaba era una especie de Historia de los sistemas operativos

Qué encontré

Neal Stephenson cuenta una historia, la historia de los sistemas operativos, no hasta nuestros días, porque el libro tiene sus añitos, pero sí una historia que resulta bastante actualizada. La verdad es que todo aquello que cuenta sobre Apple y Microsoft, todavía sigue vigente hoy en día. Hay más actores, sí (Google por ejemplo), el hardware es muy distinto (móviles, tablets), pero la esencia persiste todavía.

Conclusiones

En definitiva, el libro me ha encantado. No es sólo porque el autor critica a varias super-empresas (que siempre gusta ver cómo reciben los poderosos), no es sólo por el tono de humor que usa Neal, no es sólo porque es un libro muy geek. Es por todo eso y además porque es un clásico, y sólo leyéndolo se entiende por qué es un clásico.

Si a eso le añadimos que lo puedes adquirir libremente y que está disponible una traducción al castellano, ya no hay escusa para no leerlo.

Un libro muy recomendable, que se puede leer de una sentada (o casi)

Pasajes que quiero recordar de este libro

Solo hay dos modos de vender un producto (software): precio y funcionalidades. Cuando los sistemas operativos son gratuitos, las compañías de sistemas operativos no pueden competir mediante precio, así que compiten mediante las funcionalidades. […] Esto explica por qué Microsoft añadió un navegador a su sistema operativo, por ejemplo.

Así como la interfaz de línea d ecomandos abre un canal mucho más direcot y explícito entre usuario y máuqina que la GUI, lo mismo suced con palabras, escritor y lector comparado con Disney (que es todo imagen)

La Disney y Apple/Microsoft están en el mismo negocio: cortocircuitar la laboriosa y explícita comunicción verbal con interfaces de disño caro.

El problema es que una vez que nos hemos librado d ela capacidad de juzgar lo bueno y lo malo, loverdadero y lo falso, ya no queda cultura. La capacidad de juicio, de creencia, es el fin mismo d etener una cultura.

¿Por qué triunfan Miscrosoft y Apple si nos engañan con sus GUI’s? Porque estamos demasiado ocupados hoy en día como para comprenderlo todo con detalle. Y es mejor comprenderlo por una interfaz, oscuramente, que no comprenderlo en absoluto.

Lo primero que hicieron los hackerrs de Apple cuando consiguieron que MacOS fuese funcional fue recrear la interfaz de Unix, para poder hacer algún trabajo útil. En aquel momento, en lo que concernía a los hackers de Apple, la muy pregonada GUI del Mac era un impedimento, algo a evitar […]

Unix es el hole hawg de los sistemas operativos.

Al tratar de comprender el fenómeno Linux tenemos que contemplar no a un único innovador, sino na especia de extraña Trinidad: Linus Torvals (por Linux), Richard Stallman (por las herramientas GNU) y Bill Gates (por el abaratamiento del hardware). Elimínese cualquiera d elos 3, y Linux no existiría.

A menudo, este tipo de archivos pueden encontrarse en un directorio con el nombre /src, que es la abreviatura hebraica del hacker para source, fuente.

Si hubiera algún ordenador, en algún lugar, que pudiera escupir unikversos con valores aleatoriamente escogidos para sus constantes fundamentales, por cada universo como el nuestro produciría 10^229 universos fallidos […] así que cada vez que tu meñique pulsa ENTER, lo estás intentando.

Otras lecturas y enlaces relacionadas

Lean software development

Lean software development

Mary Poppendieck, Tom Poppendiek:

Por qué lo he leído

Después de leer Scrum y XP desde las trincheras, me quedé con ganas de leer algún libro más de temática Agile, de desarrollo de software siguiendo prácticas lean. Me llaman mucho la atención las metodologías ágiles de desarrollo de software, y creo que son una buena alternativa a las metodologías tradicionales (aunque voy descubriendo otras como FDD que parecen igualmente interesantes).

Busqué un libro antiguo, alguno donde pudiera leer los inicios de estas metodologías, para así poder contextualizar todo lo que escucho y leo de las metodologías ágiles a diario.

Qué esperaba

Esperaba un libro dedicado exclusivamente al software, que expusiera ideas que podían parecer pasadas de moda, pero que siguieran de actualidad en algún sentido.

No había oído nunca nada de los autores, así que tampoco me había formado grandes espectativas, simplemente, quería conocer los inicios de las metodologías ágiles.

Qué encontré

Me encontré un libro muy útil, y aunque es de hace bastantes años (para tratar sobre desarrollo de software), es de total actualidad. De hecho, me sorprende que todavía haya empresas, personas, organizaciones, que no hayan oido hablar de los conceptos que se hablan en el libro.

Conclusiones

Me sorprendió mucho que el origen de las metodologías ágiles esté en la industria de la manufactura. Me parece difícil que una metodología haya pasado de esa industria a la del desarrollo del software. Pero como indican los autores (y es la idea principal del libro), no se pueden transladar prácticas de un entorno a otro, hay que transladar principios (ideas) y crear las nuevas prácticas para el nuevo entorno.

Y es de lo que trata este libro, de exponer una serie de herramientas, un toolkit, para ayudar a comprender y a transladar una serie de principios, que está demostrado que funcionan en una industria, al desarrollo del software.

Otras lecturas y enlaces relacionadas

Pasajes que quiero recordar de este libro

Los siete principios del pensamiento Lean:

  1. Elimina desperdicios
  2. Amplifica el aprendizaje
  3. Decide tan tarde como sea posible
  4. Entrega tan rápido como sea posible
  5. Fortalece al equipo
  6. Trabajar para que haya integridad
  7. Centrarse en el todo

Cualquier cosa que no crea valor para el cliente es desperdicio. Y, sí, los defectos (bugs, incidencias, …) son desperdicion.

Es difícil encontrar control sin realimentación (feedback), porque la realimentación de mucho mejor control y determinismo que complicados procesos de control con algoritmos predefinidos.

En la mayoría de los casos, incrementar la realimentación, en lugar de reducirla con rigurosos procesos secuenciales, es la forma más efectiva de lidiar con entornos y proyectos de desarrollo de software en problemas.

Set-based software development: se desarrollan varias alternativas, se comunican las restricciones (en lugar de las soluciones) y se deja que la solución emerja cumpliendo todas las restricciones.

Retrasar decisiones irreversibles mientras se reduce la incertidumbre tiene valor económico. Esto lleva a tomar mejores decisiones, limita los riesgos, ayuda a gestionar la complejidad, reduce el desperdicio y hace felices a los clientes.

Los procesos de desarrollo ágiles se pueden entender como la creación de opciones que permiten retrasar las decisiones hasta que las necesidades del cliente son mejor entendidas y haya menos riesgo.

Los marines planifican, pero no predicen. Comprenden la esencia de las situaciones, buscan simplificar las suposiciones y alternan aproximaciones. Cuando entran en una misión, la estructura organizativa se diluye, y aquellos que están en el frente, quienes tienen acceso a la información más directa, son los responsables de tomar las decisiones.

El principio ‘entrega tan rápido como sea posible’ complemente a ‘decide tan tarde como sea posible’. Cuanto más rápido entregues, más podrás retrasar tus decisiones.

(hablando de los pull systems) en lugar de planificar, sistemas como Kanban consiguen que los jefes no intervengan porque cada persona sabe qué hacer en cada momento.

Creemos que transferir prácticas de un entorno a otro es, casi siempre, un error. En lugar de ello, uno debe entender los principios fundamentales detrás de las prácticas y transformar esos principios en nuevas prácticas para el nuevo entorno.

El mejor modo de mantener el conocimiento sobre un sistema y que sea mantenible es entregar, junto con el código, un conjunto de tests automáticos, complementados por un modelo superficial de alto nivel creado al final del esfuerzo inicial de desarrollo.

Integridad conceptual significa que los conceptos centrales de un sistema son vistos contínuos, como un todo cohesionado. La clave para alcanzarla es la efectividad en los mecanismos de comunicación desarrollados por los grupos que conforman el sistema según se van tomando las decisiones que afectan al resto de grupos.

¿De dónde ha tomado la genete la idea de que todo buen diseño ocurre al inicio de un proyecto? Mucha gente encargada de desarrollar productos entiende que los grandes diseños evolucionan con el tiempo.

¿Refactorizar es rehacer el trabajo? Mejorar un diseño durante el proceso de desarrollo no es rehacer el trabajo, es una buena práctica de diseño.

Los tests proporcionan una base en la que apoyarse para que los desarrolladores realizen cambios a lo largo de todo el proceso de desarrollo.

La metodologías tradicionales de desarrollo software tienen la manía de medir tareas complejas y desestructuradas a través de partir la tarea en otras más pequeñas. La forma de estar seguro de que todo está medido es mediante agregación, es decir, mover la medida a un nivel superior, no a un nivel inferior.

Un contrato con precio fijado donde el vendedor espera obtener beneficios de los cambios pedidos, combinado con mecanismos rigurosos de aceptación de cambios para controlar el gasto, puede doblar aproximadamente el coste y tiempo que se tarda en desarrollar un proyecto a la vez que produce un resultado de pésima calidad.

Un contrato de precio flexible está diseñado para lidiar con la incertidumbre y complejidad, pero esto no elimina el riesgo, sino que lo traslada del vendedor al cliente.

Scrum y XP desde las trincheras

Scrum y XP desde las trincheras

Henrik Kniberg

Por qué lo he leído

Estaba un poco cansado de leer libros técnicos, y me apetecía leer alguno más práctico, como si estuviera leyendo un caso de éxito o algo así. También me apetecía introducirme más de lleno en las metodologías ágiles, y un amigo me comentó que desde que leyó Scrum y XP desde las trincheras, su visión del desarrollo del software cambió totalmente.

Qué esperaba

Esperaba una descripción de los elementos que componen Scrum, o de las prácticas que define XP. Y también una visión práctica de las mismas.
Tenía muy buenas referencias del libro, y tenía ganas de conocer de primera mano todas las bonanzas que había escuchado sobre las metodologías ágiles.

Qué encontré

Encontré una serie de anécdotas, y una descripción de un caso real de aplicación de Scrum y XP en una empresa. Un testimonio sin igual.
El autor expone su propia experiencia trabajando con Scrum y XP, metodologías o mejores prácticas del mundo ágil que nos proporciona una idea de lo que nos podríamos encontrar si lo quisiéramos aplicar en nuestra empresa.

Conclusiones

Un fantástico testimonio que todo el que quiera conocer un caso real y exitoso de aplicación de metodologías ágiles debería leer.
Sin duda, éste es un libro que no te deberías perder.
Además, está disponible para su descarga gratuita en varios idiomas, entre ellos el español (enlace de descarga de Scrum y XP desde las trincheras). La verdad es que se agradece que existan versiones en español de libros tan interesantes como éste.

Pasajes que quiero recordar de este libro

el dueño del producto debe concentrarse en los objetivos del negocio, no en escribir historias con orientacion tecnica

otras personas aparte del dueño del producto pueden añadir historias a la pila del producto, pero no pueden asignarles orden de importancia (cometido exclusivo del dueño de producto) ni pueden establecer estimaciones (cometido exclusivo del equipo)

la planificación del sprint es una reunión crítica, la más importante de Scrum

cada historia de usuario depende de tres variables: estimación (proporcionada por el equipo), alcance e importancia (proporcionadas por el dueño del producto)

es responsabilidad del equipo mantener la calidad del sistema bajo toda circunstancia, y no es negociable nunca

la estimación es una labor de equipo, todo el equipo debe involucrarse en estimar cada historia

¡ sienta al equipo junto !

en la retrospectiva, cada persona tiene una oportunidad de decir, sin ser interrumpida, qué ha ido bien, qué podría haber ido mejor y qué piensan que debería hacerse diferente en el próximo sprint

fase de pruebas es dura, probablemente la más dura del ciclo del desarrollo de sw. la sensación es definitivamente ‘no agil’. no podemos liberarnos de ella, pero si minimizar la cantidad de tiempo necesario

casi siempre es más barato producir menos, pero hacerlo estable, que producir muchísimo y luego tener que hacer parches de emergencia

Otras lecturas y enlaces relacionadas

  1. Blog de Henrik Kniberg
  2. Manifiesto ágil (english: Agile Manifesto)
  3. Introducción a la Agilidad y Scrum

Refactorizacion: inserta un método ajeno

En este post voy a describir una de las muchas refactorizaciones que describe Martin Fowler en su libro Refactoring: improving the design of existing code (mis impresiones sobre el libro). He escogido la refactorización de insertar método ajeno por ser una de las que, aun siendo sencilla, no había sido consciente de utilizarla hasta leer el libro.

Descripción

La refactorización consiste en crear un método en una clase (clase cliente) cuando en realidad ese método debería pertenecer a otra clase (clase servidor). De ahí el nombre de método ajeno (traducción libre de foreign method)

Por qué es necesaria

Esta refactorización aparece ante la necesidad de crear un método en la clase servidor, pero es imposible cambiar el código fuente de la misma.

Cómo llevar a cabo la refactorización

Lo primero es crear un método en la clase cliente que haga lo que necesitamos que haga la clase servidora. El primer parámetro de este método será un objeto de la clase servidora. En caso de necesitar algún parámetro más, éstos serían los parámetros en caso de que el método existiera en la clase servidora.

El objetivo de crear un nuevo método es el de poder reutilizar el código y evitar duplicidades. De esta forma podremos retutilizar el código del nuevo método, y en el caso de que en un futuro podamos cambiar el código fuente de la clase servidora, ese cambio será menos doloroso.

Martin Fowler aconseja comentar el método como `método ajeno`, para poder encontrar métodos candiatos a mover a sus clases correspondientes. En mi opinión, no creo que esto ayude demasiado a la hora de mantener el código, pero tampoco lo veo perjudicial. Así que aquí, que cada cual siga sus preferencias.

Código de ejemplo

Partimos del siguiente código de ejemplo, es un ejemplo muy sencillo pero espero que ilustre el caso lo suficientemente bien como para comprender la refactorización:

// ...
Date nextDay = new Date(previousDay.getYear(), 
                        previousDay.getMonth(), 
                        previousDay.getDate() + 1);

Como vemos, nuestro código necesita varios datos de la clase servidora (Date, objeto previousDay). Si la clase Date tuviera un método nextDay, o similar, nuestro código quedaría realmente simple. Pero no lo tiene, y lo pero de todo es que tampoco tenemos la posibilidad de modificar Date para incorporarle ese método.

Está bien, creemos pues nuestro método ajeno:

Date nextDay = nextDay(previousDay);
// ...
// foreign method
private Date nextDay(Date aDay) {
    return new Date(aDay.getYear(), 
                    aDay.getMonth(), 
                    aDay.getDate() + 1);
}

Sí, el código es prácticamente el mismo, pero ahora tenemos un método, la principal forma de reutilizar código. En el caso de poder modificar la clase Date, sería trivial mover este método a esa clase. De hecho, mover método, es una de las primeras refactorizaciones (y más básicas) explicadas por Martin Fowler en Refactoring.

The Clean Coder

The Clean Coder: a code of conduct for professional programmers

Rober C. Martin

Por qué lo he leído


Me decidí a leer este libro porque leyendo varios blogs en español encontré más de una referencia, por lo que parecía un buen libro para leer. Además, conseguí que un amigo me dejara un ejemplar. Todos los requisitos cumplidos.

Qué esperaba

La verdad es que el propio título ya dice bastante: “clean coder”. Esperaba encontrar una guía de buenas prácticas para aplicar en mi día a día profesional, una serie de consejos sobre cómo desarrollar software de calidad, limpio, que sea fácil de leer. Estaba incluso decidido a soportar una lista de tópicos sobre el desarrollo del software, pero estaba seguro de que iba a encontrar consejos/prácticas nuevas y, por supuesto, iba a aprender técnicas útiles.

Qué encontré

La verdad es que no encontré exactamente lo que buscaba. Robert C. Martin nos cuenta más batallitas que otra cosa, pero no nos miente, desde el principio del libro nos advierte que éste es un libro de experiencias personales.

El libro es un conjunto de experiencias, unas buenas y otras malas, del autor, de las cuales, Uncle Bob ha aprendido todo lo que sabe.

El libro también es un conjunto de consejos, una guía, de cómo Robert cree que se debe comportar un desarrollador de software profesional.

Conclusiones

El libro me ha encantado.

El tono que usa Uncle Bob para relatar sus experiencias es informal y cercano. En algunas de ellas puedo ver reflejados a compañeros míos o incluso a mí mismo (aunque ya no trabajamos con tarjetas perforadas, pero la esencia sigue siendo la misma).

Algunos consejos son, para mi gusto, un poco extremistas, pero el autor da sus razones de porqué él cree que debe ser así. Al fin y al cabo, han sido y son sus vivencias y no las impone a nadie. Con otros consejos no estoy muy de acuerdo, pero siempre es bueno conocer otras opiniones.

En definitiva, si te preocupa tu trabajo, éste es un buen libro para conocer qué piensa una de las personas más importantes en el mundo del desarrollo del software. Así es como Robert C. Martin cree que debe ser un profesional:

  • Es responsable: cuando un profesional comete un fallo, arregla el desorden que ha provocado.
  • Usa su conocimiento para construir, no para destruir.
  • Debe estar seguro de que funciona (tests).
  • Conoce el campo en el que trabaja (banca, transporte, …).
  • Nunca ridiculiza a los demás.
  • Trabaja duro para encontrar caminos creativos para decir “si”, para entregar funcionalidad.
  • La actitud que tiene hacia las interrupciones es de mostrarse voluntarios de poder ser de ayuda. Se ofrece a ayudar a los compañeros si ven que están teniendo problemas.
  • Programa en parejas.
  • Mantiene la mente abierta a nuevas tecnologías, ideas, diseños, y acepta que estas novedades pueden ser incluso mejor que las actuales.

Pasajes que quiero recordar de este libro

Debes ser responsable de tus imperfecciones, lo primero que debes aprender es a pedir perdón, después debes hacer que tu ratio de errores tienda a cero.

Entregar funcionalidad a coste de romper la arquitectura es un error de principiante. Comprometer la arquitectura es comprometer el futuro.

Regla del Boy Scout: deja siempre el código un poquito más limpio de lo que te lo encontraste.

Tu carrera es tu responsabilidad, no culpes a tu empresa.

La mejor forma de aprender, es enseñando. Otra forma de aprender es colaborar con otra gente.

Los problemas de tu empresa (quien te paga) son tus problemas.

Programar es un acto de creación. Cuando escribes código, estás creando algo de la nada.

(Sobre estimaciones y compromisos) Negocia para alcanzar el máximo de las dos partes enfrentadas.

La promesa de “lo intentaré” es la aceptación de que guardas un esfuerzo extra, y además es un compromiso de que necesitarás aplicar ese esfuerzo extra para conseguir el objetivo.

Agresión pasiva: dejar que tu compañero falle públicamente cuando sabes de antemano que lo que está haciendo fallará.

Dilo, comprométete y hazlo. (no lo intentes, hazlo)

Programar es una actividad agotadora, que reta tu inteligencia […], si estás cansado o distraído, no programes.

Las estimaciones tienen que estar basadas en datos, no incorpores esperanza en tus estimaciones. Y no dejes que los demás tengas esas esperanzas.

No aceptes hacer horas extras, excepto si: te lo puedes permitir personalmente, es para un período corto y tu jefe tiene un plan B por si no funciona.

La única forma de mejorar la planificación, es reducir el alcance. No caigas en la tentación de correr.

Los tests te dan la certeza suficiente para entregar.

TDD (desarrollo dirigido por tests) es una disciplina que mejora la certeza, el coraje, reduce los defectos, la documentación y mejora el diseño.

Katas:

Tom DeMarco: Una ambigüedad en los requisitos, refleja un conflicto en el cliente.

Los tests unitarios y de aceptación, primero son documentos y luego tests.

Nada tiene un efecto tan negativo a largo plazo en la productividad de un equipo desarrollador como la deuda técnica.

Programar conlleva trabajar con gente. Si quieres pasar tus días desarrollando software, deberás aprender a hablar con la gente.

Lleva tiempo que un equipo funcione, por eso, las empresas profesionales, organizan proyectos alrededor de equipos que funcionan, nunca forman equipos alrededor de proyectos nuevos.

Nikola Tesla: el genio al que le robaron la luz

Nikola Tesla: el genio al que le robaron la luz

Margaret Cheney

Por qué lo he leído


Suelo leer microsiervos bastante a menudo, y en ese blog son admiradores de Tesla, así que ya tenía cierta introducción acerca de él. Hace tiempo, publicaron una reseña del libro y me llamó la atención. Mi cumpleaños estaba cerca, así que aproveché la oportunidad para pedir un regalo. Y así llegó a mis manos.

Qué esperaba

Ésta es mi primera biografía, asi que no tenía mucha idea de lo que me podía encontrar. Quizá una lista de fechas y logros realizados por Tesla, una serie de sucesos personales, qué se yo. Dada la reputación que le daban en microsiervos, no podía haber nada malo. Al fin y al cabo, pese a quien le pese, Nikola Tesla es bastante conocido como inventor, aunque yo lo catalogaba más como científico, y ésta es la primera biografía en castellano (aunque es una traducción), así que esperaba llegar a conocer en profundidad a un personaje fundamental para entender el mundo tal y como lo conocemos hoy.

Qué encontré

Encontré el relato de una vida, una enumeración de hechos bastante bien documentados, pero no sólo una mera enumeración, como la vida misma, todos los eventos se interrelacionan, todos los personajes (en este caso, personas reales con los que Tesla tuvo relación) se relacionan en una serie de actos sociales, de logros científicos, de descubrimientos, de disputas sobre patentes, empresas que se crean y acaban por desaparecer, …
El libro me ha conducido por las distintas fases de la vida de Tesla, y describe a Tesla con gran admiración pero también con fuentes contrastadas y documentadas, aunque a veces no fuera posible dado que hay cierto halo de misterio en torno a muchos de los proyectos en los que trabajó Tesla.

Conclusiones

En general es un libro que me ha gustado mucho leer, del cual he aprendido mucho sobre la vida de una persona tan extraordinaria como es Nikola Tesla.
También creo que he podido disfrutar del libro gracias a mi edad, creo que si lo hubiera leído con 25 años no me hubiera gustado nada, no podría haber disfrutado del recorrido de una vida. Ahora paso justo de los 30 y voy entendiendo que la vida es un largo camino donde a las locuras de la juventud le siguen los grandes logros de la madurez.
Al final del libro me he quedado algo apenado, ya que según describe el libro, Tesla tenía muchas manías y un temperamento bastante fuerte (especialmente al final de su vida), casi hasta el punto de parecer como si tuviera alguna enfermedad mental. De todas formas el libro me ha dado a conocer aspectos de la vida de Tesla de las que no tenía ni idea, y me ha convencido de que Tesla era sobretodo un tipo extraordinario, con una imaginación sobresaliente y que debido a eso era un hombre adelantado a su tiempo, muchas veces incomprendido y que tuvo que superar tremendas dificultades. Las más difícil, en mi opinión, es el rechazo al reconocimiento que se merecía, y que lo obtuvo a título póstumo. Muy injusto.