archivo

Archivos Mensuales: octubre 2010

Es difícil encontrar organizaciones en las que existe departamento de desarrollo y departamento de sistemas en las que no haya habido o haya conflictos y eso es debido al diferente enfoque que cada cual da a su trabajo, cosa comprensible ya que se trata de tareas diferentes, a la falta de comprensión mutua y a la pérdida de visión de los objetivos del servicio que el departamento de informática debe dar, pasándose a una serie de objetivos personales que por muy buena voluntad que se tenga, en la mayoría de los casos, ponen freno, precisamente, a la consecución de dichos objetivos globales.

Como sabéis, yo pertenezco al área de desarrollo y podía ponerme la camiseta de los de mi equipo y empezar a repartir estopa, pero no sería justo porque de igual forma que conozco muchas de las debilidades de los departamentos de sistemas, conozco todavía más debilidades de los departamentos de desarrollo, algo lógico porque es donde centro mi actividad laboral. Creo que no sería constructivo un artículo ombliguista en el que todos lo que hacemos los desarrolladores sea bueno y todo lo que hacen los de sistemas sea malo, tampoco sería constructivo si no especificase los comportamientos de cada mundo que acertados o erróneos no son comprendidos por la otra parte.

Los desarrolladores tenemos que responder ante el usuario por los problemas relacionados con los sistemas de información, tanto los que se encuentran en producción como los que están en desarrollo y puedo asegurar que los usuarios no se caracterizan especialmente por su paciencia. Además sea cual sea la causa del problema siempre echarán la culpa al programa o programas que utilizan, aunque éste sea debido por circunstancias que nada tienen que ver con él. Si falla la red, si se cae el servidor o pasa cualquier otra cosa es la aplicación el origen de todo mal. Esto aunque injusto, es razonable, ya que los usuarios no tienen por qué conocer toda la infraestructura que tiene un sistema de información para que funcione y ellos lo que notan es que el sistema no funciona, que va lento o cualquier otra contingencia.

Cada vez que sucede una incidencia de esas características se traduce, en función del tiempo que se tarde en resolver, el momento en el que se haya producido y el número de usuarios implicados, en trabajo, ya que habrá que volver hacia atrás tareas que no se han ejecutado correctamente y lo que es más importante, falta de confianza de los usuarios en la aplicación y en el equipo de personas que está detrás. Cuesta mucho ganarse el respeto y la confianza de los usuarios y sin embargo, perderlo, es mucho más sencillo.

También es cierto que la mayoría de los problemas que tienen las aplicaciones no son consecuencia del departamento de sistemas, sino porque las mismas tienen problemas funcionales y/o no funcionales que han llegado hasta la puesta en producción y esto es responsabilidad del departamento de desarrollo y/o de los usuarios si estos no han definido bien los requisitos o no han colaborado lo debido en todo el proceso.

Si la mayoría de los problemas que tienen las aplicaciones son resultado del proceso de desarrollo, ¿por qué nos fastidia/altera/mosquea tanto que de vez en cuando haya pérdidas de disponibilidad total o parcial de las mismas? Pues porque cuesta menos dar la cara cuando el problema es de tu responsabilidad que cuando es de otro y la cosa es que en la mayoría de los casos, independientemente de la naturaleza de la incidencia es el departamento de desarrollo el que recibe las “caricias” de los usuarios.

Otro problema que nos encontramos los desarrolladores con respecto al departamento de sistemas (o viceversa) es la existencia de prioridades distintas (en realidad son compatibles, pero nosotros mismos hacemos que cada una siga su propio camino) y esta circunstancia es la que favorece la creación del fenómeno de los dos mundos.

La prioridad de los desarrolladores es que los sistemas de información permitan el trabajo de los usuarios de la manera más eficientemente posible y, además, que el tiempo de respuesta ante las incidencias de las aplicaciones sea el menor posible. La prioridad de los departamentos de sistemas está en mantener la disponibilidad de los sistemas físicos, servidores y comunicaciones, así como establecer las medidas de seguridad apropiadas para evitar intrusiones o acciones no permitidas sobre cualquiera de los elementos anteriores.

Hasta ahí, todo bien, el problema está cuando los desarrolladores damos cabida a soluciones que no son compatibles con las políticas del departamento de sistemas o que requieren soluciones que muchas veces no están en su mano (los medios, memoria, procesador, etc… no son infinitos), de manera que pedimos la instalación de servidores nuevos, más memoria, más procesador, nuevas soluciones de bases de datos, etc… además de otros aspectos relacionados con las políticas de seguridad (apertura de determinados puertos, más capacidad de acceso a bases de datos, servidores, etc…,) generalmente, además, sin dar excesivo margen de maniobra en cuanto a buscar otras alternativas, ya que avisamos cuando ya se está trabajando en la solución o está terminada.

Como es lógico estas situaciones causan desgaste ya que por un lado los desarrolladores demandamos que se pongan a disposición de las aplicaciones las infraestructuras que creemos que se necesitan y pensamos, al no existir el tiempo de respuesta que nos gustaría, que los de sistemas viven en otro mundo, ajenos de los problemas del día a día de las aplicaciones y de los usuarios, y por otro los de sistemas piensan que no actuamos con perspectiva, que somos un desastre y que pretendemos resolver a base de fuerza bruta lo que no hemos sabido solucionar en el proceso de desarrollo.

En relación a este asunto, tengo que dar la razón a los de sistemas, ya que se suelen enterar demasiado tarde y eso es debido a que no se les consulta si una determina solución les parece adecuada con sus políticas e infraestructura. En el caso de que sea estrictamente necesario hacer una modificación en las mismas, además hay que darles tiempo para que puedan pensar en otras alternativas o a formarse o familiarizarse con lo que les hemos pedido que instalen y/o administren.

Otro problema que también ocurre con bastante frecuencia es el exceso de celo que a veces los del departamento de sistemas ponen respecto a determinadas políticas de seguridad, muchas veces desproporcionadas respecto a la realidad existente y basadas generalmente en apreciaciones personales más que en decisiones del propio colectivo del departamento.

Es necesario que desde sistemas establezcan las políticas, sería un error que desde desarrollo se impulsasen las mismas, pero es necesario que las mismas sean generales y conocidas y no se deje al criterio del personal su endurecimiento o reblandecimiento. Además es necesario que las normas que se dicten sean racionales con la realidad de la organización y sus capacidades, ya que a veces las mismas provocan un incremento de complejidad en el proceso de desarrollo o de gestión de los proyectos totalmente innecesario.

Muchos de estos problemas quedarían resueltos o, al menos, paliados si existiesen unas normas por escrito que rigiese el funcionamiento de los departamentos de desarrollo y de sistemas y si, además, los responsables de los mismos, siempre dentro de la profesionalidad y pensando en el interés general de la organización, llegasen a soluciones de consenso en aquellas excepciones, que seguro se producirán, que haya que estudiar por no cumplir parcial o totalmente las normas.

Además de todo lo anterior es necesario el respeto. Los desarrolladores tenemos que entender que los de sistemas conocen mejor la problemática del mantenimiento de las infraestructuras que nosotros y ellos deben entender que nosotros conocemos mejor la problemática del desarrollo y mantenimiento de los sistemas y las apreciaciones de los usuarios. También es necesario entender que ambos trabajos no son fáciles y que en muchas ocasiones, actuamos desde situaciones exigentes y con presión. Todos nos vamos a terminar equivocando, no una, sino cientos de veces y tenemos que intentar ser comprensivos.

Es difícil alcanzar la situación ideal en que los departamentos de sistemas y de desarrollo no sean dos mundos con objetivos dispares, sino uno solo que verifique el objetivo final de cualquier departamento de informática y que no es otro que dar el mejor servicio posible y eso solo se puede conseguir si todas las partes involucradas reman en la misma dirección.

Raymond Edward Ozzie es desde mediados de 2006 arquitecto jefe de software de Microsoft sustituyendo en ese puesto al mismísimo Bill Gates (que se ha declarado admirador de su trayectoria), antes trabajó en empresas importantes como Lotus Development e IBM, además de emprender aventuras empresariales de éxito (sus empresas terminaron siendo adquiridas por otras más fuertes). Dentro de su trayectoria profesional se especializó en el software de trabajo en grupo, formando parte del grupo de desarrollo de Lotus Notes, software con el que se comenzó a trabajar hace maś veinte años y que en la actualidad, con las sucesivas versiones que han ido apareciendo, sigue en la brecha con una gran cuota de mercado.

Además de la trayectoria profesional exitosa de Ray Ozzie, su nombramiento también ha sido resultado de su conocimiento y experiencia en la integración entre el trabajo en grupo e Internet y se haya visto en él la persona capaz de establecer un puente entre las soluciones de escritorio de Microsoft y el enfoque actual de usuarios y aplicaciones que no es otro que la red.

Una de las citas más conocidas de Ray Ozzie es que “la complejidad es destructiva. Chupa la sangre de los desarrolladores, hace que los productos sean difíciles de planificar, construir y probar, introduce problemas de seguridad y provoca la frustración de usuarios finales y administradores”.

No puedo estar más de acuerdo con él, cuanto más complejo es el software que se desarrolla más problemas tendrá en todas las fases de su ciclo de vida y por tanto, más esfuerzo y coste tendrá asociado. Es cierto que cada aplicación o sistema que se desarrolla tiene una complejidad inherente, pero también lo es el hecho de que los desarrolladores tendemos a añadir un plus de complejidad al producto. Esto es así porque en muchas ocasiones nos empeñamos en tirar de teoría a la hora de hacer los sistemas, en otras porque intentamos que el sistema esté integrado con todo lo integrable y en otras porque intentamos que la primera versión del producto sea la definitiva, en lugar de realizar desarrollos iterativos que reducen complejidad y permiten que los usuarios se vayan adaptando al sistema e ir moldeando con la experiencia los requisitos funcionales.

Hay que hacer convivir la simplificación con las necesidades en materia de organización de sistemas que esté implantada, es decir, lo más fácil por ejemplo es que la aplicación tenga su propio sistema de terceros, tenga en tablas propias información que se mantiene preferentemente en otras aplicaciones, que se rehúse a utilizar soluciones corporativas, etc…, pero si en todos los casos se aplicase esta filosofía de funcionamiento lo que tendríamos al final es una multitud de sistemas estanco con información redundante y con el paso del tiempo, incoherente. No es sencillo encontrar el justo medio en esto, como tampoco lo es determinar hasta dónde se llega en la primera versión del sistema ni qué soluciones aplicar a nivel funcional, de arquitectura, de codificación, etc…

En cualquier caso lo que hay que plantearse es que si hay dudas se vaya siempre por el camino más fácil (ya habrá tiempo de soluciones más elaboradas o complejas). Insisto, si hay dudas, si sistemáticamente vamos a por lo fácil resolveremos algunas cosas pero a la vez crearemos nuevos problemas.

Por otro lado, tal y como comenta Ray Ozzie, la complejidad es algo que al final sufrimos todos, cliente, proveedor, usuarios, departamento de sistemas, departamento de explotación y que provoca, al ser una fuente continua de problemas, un gran desgaste.

Según muchos expertos en marketing, la marca importa tanto en tiempos de crisis como en momentos más halagüeños, pero sobre todo en épocas donde la economía no está tan boyante y en donde no se quiere especular o arriesgar en los resultados.

El desarrollo de software no es ajeno a esto y muchas empresas, sobre todo aquellas que pueden permitírselo, acuden a empresas conocidas para realizar el mantenimiento y/o el desarrollo de sus sistemas de información. Prefieren pagar más, pero a cambio tener un cierto grado de seguridad de que el resultado de los trabajos será satisfactorio.

Las empresas más pequeñas podrán pensar: “bueno, de todas formas, esos contratos son tan grandes que no tenemos infraestructuras para abordarlos, por lo que me da igual que competencia con más nombre se haga con ellos, además, lo mismo hay suerte y hasta me subcontratan, en algún caso, parte del trabajo.”.

Lo anterior podría no ser un problema si no sucediera algo que se ha convertido ya en un hecho y es que muchas de esas empresas grandes o de renombre, han decidido también irse a por trozos de tarta más pequeños. Esto en cierto modo es razonable ya que los trozos de tarta grandes son menos (y de menor tamaño) por lo que para compensar no hay más remedio que irse a por contrataciones que en otros tiempos, tal vez hubieran descartado ya que para ese tipo de empresas el overhead que tienen muchos contratos pequeños no les termina de compensar. Seguramente para conseguir rentabilidad en este tipo de trabajos hayan tenido que hacer variaciones en sus procesos productivos y de gestión, cosa lógica si se quiere ser competitivo en estos otros mercados.

¿Es tan importante la marca en el desarrollo de software? yo lo respondería a esta pregunta con otras, para ti como persona, ¿es importante la marca?, ¿compras marca o producto?, ¿prefieres marca aunque te cueste algo más caro?, ¿asocias marca a calidad?, ¿confías más en una marca conocida que en otra que no lo sea tanto?, seguramente en la mayoría de los casos triunfaría la marca, pues también en la mayoría de los casos triunfará la marca cuando existan unas condiciones parecidas entre las diferentes empresas que luchen por hacerse con un contrato.

Mi opinión es que no hay una solución universal (no hay que cerrarse en la marca o en el nombre, porque ni uno ni otro hacen análisis funcionales, diseños técnicos y programan), es decir, habrá que estudiar exáctamente qué es lo que se quiere contratar, su impacto en la organización y el presupuesto del que se dispone (entre otros muchos factores) y a partir de ahí empezar a escuchar y a leer compromisos por escrito (entre lo que se dice y lo que se escribe hay muchos, muchísimos matices).

Bill Gates hizo la siguiente cita: “Un gran operario de tornos vale varias veces más que un operario medio, pero un gran escritor de código vale 10.000 veces el precio de un desarrollador medio”.

Robert Glass cifraba la proporción en, al menos 28 veces.

Como es lógico, tanto una cifra son utilizadas por sus autores simplemente para llamar la atención de que en el mundo del desarrollo de software no hay dos personas iguales y por tanto, cuando hay cambios, hay consecuencias en el proyecto, ya que además del período de aclimatación al mismo, que puede ser más o menos rápida y más o menos compleja en función de su naturaleza y estado, quien sustituye a quien no está, puede tener mejores o peores cualidades para el puesto que va a desempeñar (lo mismo supera o es peor que la persona que ocupaba su puesto en otros ámbitos del desarrollo de software, pero las consecuencias en el proyecto se tienen que medir por las tareas que va a realizar en el mismo, independientemente de otras capacidades que se tengan o no), por este motivo cuando se van a realizar cambios en un proyecto hay que tener en cuenta el posible impacto que se puede producir en el mismo.

Lo anterior es extensible a la sustitución de personal en la organización ya que la marcha de piezas importantes puede provocar un trastorno importante ya que lo mismo el coste de su ausencia o de su sustitución, a corto, medio y largo plazo puede tener efectos negativos en la organización. Nadie es imprescindible, eso lo tengo muy claro, pero evidentemente es complicado que no haya un impacto cuando personal valioso abandona la nave.

También se puede ver esto desde otra perspectiva, ya que la entrada de personal con grandes capacidades en el área en el que vaya a trabajar puede aportar muy buenos resultados (la capacidad no es sinónimo de éxito, ya que es necesario que encaje en el engranaje y realidad de la organización, algo que no siempre es sencillo) y dar un giro positivo (aunque los efectos no se tengan por qué notar a corto plazo) a la marcha de todo.

La cita se refiere a los desarrolladores, pero yo la extiendo a cualquier tipo de rol, quién es muy bueno lo es y es capaz de obtener mejores resultados que la media y de aportar mucho a la organización, por lo que siempre que se pueda es necesario preservar los recursos humanos de calidad.

Los extremos no suelen ser buenos, estamos hartos de escuchar eso y algo habrá, por tanto, de cierto.

La confianza no es inmune a esto y la mayoría de nosotros habrá sufrido lo que supone tanto la falta como el exceso de confianza, personalmente he caído en los extremos en muchas ocasiones, lo que me ha servido para darme cuenta de que es una emoción que es necesario controlar y que aunque a veces se me escape de las manos, que cada vez sea en menos ocasiones.

Recuerdo un examen que me preparé bastante fuerte, en este aspecto no suelo ser de medias tintas o me preparo y echo el resto o ni siquiera lo intento, sin embargo el tiempo que dediqué a la preparación no fue el mismo que en otras ocasiones lo que hizo que no las tuviera todas conmigo, además era un examen donde no importaba si aprobaba o no, solo valía si quedaba entre el número de plazas que había disponibles. Dado que éstas eran pocas, el número de candidatos muchos y mi preparación, aunque buena, no había sido todo lo extensa que otras ocasiones, hizo que fuera al examen derrotado de antemano.

¿Qué pasó? Pues que al final se quedaron plazas sin cubrir porque el examen fue bastante difícil. Yo tampoco aprobé, pero salí del mismo sabiendo que podía haberlo hecho mejor ya que no rendí al máximo, no fui inteligente haciéndolo y me faltó creérmelo. Estas autolimitaciones provocaron que hiciera el examen al 70% o al 80% de mis posibilidades y eso es la diferencia entre estar dentro o estar fuera, así de fácil (quedé a dos décimas de aprobar y de quedar entre los “elegidos”).

El exceso de confianza tampoco es bueno ya que te quita visión crítica (pensar que todo se hace bien) y te resta esfuerzo. En el momento que no dedicamos a las tareas lo que ellas requieren de nosotros los resultados se verán mermados. Se puede tener mucho talento pero si el exceso de confianza provoca que levantemos el pie del acelerador y que además nos distraigamos, se igualarán las fuerzas con aquellos que parten de una situación más desfavorable, es más, generalmente quien viene de atrás, termina ganando.

No hace mucho tuve una charla con un amigo que es totalmente partidario de los procesos de industrialización del software y que entiende el proceso de desarrollo, una vez elaborado el análisis, como si fuera una cadena de montaje.

Me comentaba que conseguir eso implicaba trabajar, hablando en términos muy generales, de la siguiente manera:

– Los analistas discutirían el diseño del sistema con los arquitectos (en el caso de que hubiera alguna contingencia que hiciera necesario esto).

– Los analistas entregarían el diseño a uno de los responsables de recepción de trabajo de la factoría que se encargaría de distribuir el trabajo en el equipo.

– Dentro del equipo de la factoría habría un perfil asignado al proyecto que se encargaría de ensamblar los componentes y de verificar si el sistema cumple las especificaciones del diseño y del análisis.

– Una vez construido el proyecto (o en diversas iteraciones) el mismo pasaría a ser revisado por un departamento de calidad que haría las verificaciones finales del producto previas a la entrega.

La visión de mi amigo no es ni mucho menos mala, es simplemente otra opción en el proceso de desarrollo de software, es otra manera de hacer las cosas y que puede ser muy rentable si se dan las condiciones necesarias (o se reunen muchas de ellas para trabajar de esa manera).

Algunas de esas condiciones pueden ser las siguientes:

– El proceso de desarrollo de software desde su concepción hasta su entrega está regido por procesos, de manera que en cada fase cada cual conozca su rol y las tareas que debe realizar. Existirían personas encargadas de velar por el cumplimiento y mejora continua de los procesos.

– Los requisitos se encuentran cerrados en el momento en que se entrega el diseño a la factoría. Todos sabemos que eso es bastante complicado de conseguir ya que muchos usuarios terminan por afinar el concepto que tienen de aplicación conforme van viendo plasmada su construcción y a veces estos detalles son los que marcan las diferencias entre una buena terminación y otra no tan adecuada. Esto se complica sobre todo si el proyecto es de gran magnitud.

Pese a que es complicado y yo personalmente soy partidario de ser lo suficientemente flexible con el usuario y dar la posibilidad de introducir cambios menores en los requisitos más allá del análisis (con el coste y riesgos que ello conlleva), si el analista funcional hace un buen trabajo y/o se prevén fases de mantenimiento evolutivo posteriores y/o se opta por un desarrollo incremental del sistema sí que sería posible un escenario donde los requisitos estuvieran debidamente cerrados (no necesariamente al 100% pero sí muy aproximado a ese límite) en la fase de construcción.

Un inconveniente que se puede plantear con esta dinámica de trabajo es la separación entre el equipo funcional y el equipo que realiza la construcción del sistema de información. Esa frontera puede ser causa de problemas salvo que se establezcan mecanismos adecuados de interlocución entre el equipo de personas que construyen y los analistas funcionales, supuestamente si todo estuviera bien especificado en el diseño y en el análisis la comunicación no debería ser necesaria, pero eso es un modelo teórico a mi juicio ya que requeriría que no quedasen resquicios en el diseño y en el análisis, algo que resulta muy complicado y que se complica todavía más conforme se incrementa la complejidad y tamaño del sistema.

Si los mecanismos de interlocución funcionan y todos reman en la misma dirección, estos problemas pueden minimizarse, pero si no es así el equipo de construcción tenderá a rellenar los huecos del análisis y el diseño, algo que es muy arriesgado ya que ellos no han participado en la etapa de definición funcional de la aplicación y no han trabajado con quienes van a utilizar finalmente la aplicación.

Podría pensarse que la colaboración entre los equipos de trabajo debería ser algo fluido, pero no necesariamente va a ser así, sobre todo si los responsables funcionales y los del proceso de construcción son distintos y pertenecen a departamentos diferentes, lo que implicaría que el jefe común entre ambos equipos estaría situado bastante por encima en la jerarquía de la organización, lo que dificultaría las tareas de coordinación en caso de conflicto (cuanto más arriba esté quien realiza estas tareas, pierde la visión del día a día, este tipo de problemáticas no les resulta de interés, en función de otras que suelen tener (principalmente de carácter económico de los proyectos o departamentos a su carga) y además asusta más requerir su participación porque se piensa que su intervención puede ser semajante a la de un elefante cuando entra en una cacharrería).

– La construcción tiene que ser lo más homogénea posible. Es decir, en la medida de lo posible los desarrollos deben estar construidos siguiendo el mismo framework y automatizándose en lo posible el proceso de construcción mediante la utilización de generadores de código e incluso con la posibilidad de utilizar frameworks gráficos. Esto será posible cuando los clientes planteen libertad en cuanto a framework o arquitectura o exista un alto grado de compatibilidad entre la solución que requiere el cliente y aquella con la que se trabaja, en otros casos tales como aplicaciones desarrolladas siguiendo otra estrategia (y en las que se va a realizar mantenimiento evolutivo) o nuevos desarrollos que sigan otro framework habrá que aplicar otro tipo de estrategias para hacerse cargo de ellos.

Cuando el desarrollo sigue una línea diferente a la utilizada en la factoría lo ideal sería especializar un grupo de trabajo en el desarrollo con esa arquitectura, framework o tecnología, pero eso requeriría una vinculación a medio o largo plazo con el cliente y/o tener expectativas más o menos ciertas de negocio. ¿Por qué especializar? Pues porque la productividad va a ser mayor, no ya solo por el dominio que este equipo puede tener de la tecnología, sino porque se pueden adoptar soluciones (aunque sea paulatinamente) para mejorar el rendimiento en el desarrollo. Si el proyecto no es lo suficientemente grande, duradero o las expectativas de trabajar en otros proyectos similares no están claras, lo mismo hay que plantearse que la solución más adecuada no pasa porque el contrato (en el que caso de que se quiera o pueda asumir) lo realice la factoría, lo mismo resulta mucho más adecuado formar un equipo de proyecto tradicional para llevarlo a cabo.

En la charla, mi amigo tenía muy claro que había que invertir en el framework, en la generación de código y en la reutilización de módulos y componentes y que es absolutamente necesario tener a personas dedicadas exclusivamente a mejorarlo, a corregir incidencias y a asesorar y que había que perder el miedo a tener estas personas haciendo estas funciones, ya que aunque sean perfiles altos (deben serlo para que el resultado de sus trabajos sea el más óptimo posible debido al impacto que tendrá en el conjunto de proyectos) el retorno de la inversión está asegurado.

Hace bastante tiempo escribí un conjunto de articulos dedicados a la producción industrializada de software, si queréis echarle un vistazo os dejo a continuación sus enlaces:

Producción industrializada de software I
Producción industrializada de software II
Producción industrializada de software III
Producción industrializada de software IV
Producción industrializada de software V
Producción industrializada de software VI

Hace unos días terminé de leerme el libro “¿Por qué somos cómo somos?” y me ha parecido una lectura totalmente recomendable. Punset es un excelente divulgador y hace bastante ameno e inteligible un libro que podría resultar, dada la temática que trata, complejo en algunos de sus capítulos.

A través del libro podemos apreciar como buena parte de nuestra conducta es el resultado de nuestra propia fisiología y del contexto cultural en el que nos encontramos, para explicarnos esto hace un recorrido desde la formación de nuestro planeta, las primeras etapas de la vida en la Tierra hasta llegar a algunas funciones básicas de los seres humanos como el lenguaje, la comunicación, la memoria, las relaciones, la reproducción y los sentimientos. Todo ello con opiniones de expertos en cada una de las materias que se tratan exponiendo en algunos casos diversos puntos de vista sobre un mismo tema, con el objeto de que conozcamos diversos enfoques y que seamos nosotros mismos los que saquemos nuestras propias conclusiones.

Como no podría ser de otra forma el libro no da una solución a ¿por qué somos como somos? porque entre otras cosas no se ha alcanzado un nivel de conocimiento suficiente como para descifrar esa ecuación, no obstante todos los retazos que deja nos permite comprender por qué funcionamos de una determinada manera en algunos aspectos de nuestro comportamiento.

Me parece muy interesante la parte donde habla del cerebro plástico y de la capacidad que tenemos de poder “entrenar” áreas concretas del mismo en función de las actividades que realicemos y que esa posibilidad se tiene desde etapas muy tempranas de nuestra existencia.

Podríamos decir que nuestra propia anatomía es como un gran ordenador y que los cambios culturales en el ser humano y nuestro propio contexto cultural formarían parte de nuestro sistema operativo, no constituyen el núcleo pero sí que condicionan algunos aspectos de nuestro comportamiento hacia dentro de nosotros mismos y hacia fuera.

Independientemente de que aspectos fisiológicos y culturales nos sitúen en un camino concreto somos nosotros mismos los que podemos instalar los programas que regirán nuestro comportamiento, al final, elegimos nosotros y eso es lo más importante.

En la vida diaria también ocurre así, cuando tomamos decisiones siempre lo hacemos basados en el contexto de una determinada situación y esas circunstancias influyen en el rango de decisiones que podemos tomar, pero al final la que se elige es el resultado de una selección personal nuestra.