Buscar este blog

viernes, noviembre 09, 2012

Nos vemos en el otro lado

Bueno, ya es oficial, me he mudado a Wordpress.

Han sido unos cuantos años desde que empezase a escribir en este blog, en los que he generado un contenido interesante (al menos para mi), que me gustaría conservar. Pero la dejadez de Google hacia su propio servicio, Blogspot, que me ha servido durante estos 6 años, me ha convencido dar el paso a una plataforma de blogging mejor y más completa. Una desde la que pueda hacer uso de las características de Word 2010/2013 para publicar, por ejemplo. Muy cómodo y conveniente.

Así que desde hace unos días, los interesados podéis apuntaros el blog al que he migrado todos los contenidos y donde seguiré escribiendo a partir de ahora: http://jbolano.wordpress.com

Nos vemos en el otro lado.

jueves, septiembre 27, 2012

Una breve historia del desarrollo de software

 

  dishi

Disclaimer: este artículo es un simpático ladrillo que me ha encantado escribir.

El desarrollo de aplicaciones informáticas tiene muchos nombres y variantes hoy en día:

Desarrollo de software, desarrollo informático, hacer webs, escribir apps, programación a secas, tirar líneas, o simplemente “Desarrollo” si estás en el mundillo. Cada uno usa la expresión que mejor le parece por historia, conocimiento o costumbre, pero en general, todos sus nombres pierden por el camino la esencia, historia y detalles de lo que es el desarrollo de aplicaciones.

Conocida oficialmente en su origen como programación, este noble arte (algunos dicen que ingeniería, otros hablan de craftmanship, e incluso hay quien lo concibe como juego o deporte) se inició en su forma actual* con máquinas muy distintas, en forma y tamaño, a las que conocemos hoy día: monstruosas toneladas de vidrio y metal que ocupaban enormes habitaciones y cuyo coste alcanzaba sumas tan solo al alcance de gobiernos y corporaciones.

Estrictamente hablando, el acto de programar estas máquinas en los años 40 tenía poco de soft y mucho de hard, dado que se realizaba primero mediante la manipulación del propio cableado y luego mediante instrucciones en tarjetas de cartón perforado (elementos físicos todos).

Tras ese pasado remoto de tarjetas perforadas y bombillas de colores, vinieron los monitores de fósforo verde y la miniaturización a lo largo de 30 años, posibilitando el alunizaje del difunto Armstrong en su misión Apollo de 1969. Alrededor de 10 años más tarde, en los 80, las masas identificarían a Bill Gates y Steve Jobs como los iconos de esta época, pero no los únicos. Quizá muchos recordemos los Spectrum, Comodore y Amiga que tantos padres metieron en casa para sus hijos, junto con las enciclopedias y vídeos Beta o VHS.

Toda esta generación de los 80 se basaba en cintas y discos magnéticos para almacenar los programas, soportes como como los anacrónicos disquetes que aun vemos en los botones de “Guardar” de la mayoría de aplicaciones. Esto permitió al común de los mortales no solo poder guardar sus datos y programas. Sino también crearlos sin tener que gastar una fortuna en tiempo y dinero usando cartones o hilos de cobre. Habíamos dado un salto de gigante en el desarrollo de software en cuanto a coste y velocidad de creación y distribución. De repente, todo el mundo era un creador de software y contenidos digitales en potencia.

Una vez extendidos a las oficinas de todo tamaño y metidos en las casas de los early adopters, la tecnología mutó la forma y los usos del aparato, desde la torre beige, al portátil negro o plateado y el netbook multicolor, mientras veíamos Cheers, Corrupción en Miami y Los Vigilantes de la Playa, los ordenadores se convirtieron cada vez más en un objeto personal, de esos que llevas contigo a todas partes.

Sin lugar a dudas en los 90 y 00’s llegamos a tener “un PC en cada hogar” aunque no exactamente como deseaba Gates si reparamos en la manzana que adorna ciertas máquinas Intel. Sin embargo, a mi juicio, lo más interesante de los ordenadores en los años 90 fue: 1) la capacidad de conectarse entre sí (localmente y por Internet), y 2) la conversión de esta herramienta de trabajo y juego, en herramienta de creación y comunicación multimedia de facto. Quien más y quien menos, hizo entonces (y hoy) uso de: correo electrónico, redes sociales (primitivas, eso sí), cámaras de foto y video digitales… y foros de desconocidos con intereses comunes. Curiosamente este uso de los foros es quizá lo más espectacular de todo, pero supongo que es cuestión de opiniones.

Si no te da vértigo comprender que el ordenador pasó en solo dos décadas de mera herramienta de trabajo y entretenimiento, a ser a la vez, tanto El Canal como La Herramienta Universal, es que no lo has entendido nada. La mayoría de la gente sin embargo sí lo entendió, y con ello su potencial se volvió ilimitado: comercio, medicina, política, astrofísica, publicidad, crimen organizado… nada le fue ajeno desde finales de los 90. Y por eso mismo terminó hinchando la Burbuja Puntocom, pero eso es otra historia y ahora estamos más preocupados con la burbuja inmobiliaria y de deuda soberana Europea.

En cualquier caso, la programación pega otro vuelco y se comienzan a escribir código libre y abierto por grupos internacionales de desconocidos, se produce el equivalente a la explosión del Cámbrico en los virus informáticos y el navegador y los servidores web se convierten de facto en una plataforma de desarrollo de primer orden.

Finalmente, en la primera década del siglo XXI, ayer mismo, el mundillo se revuelve de nuevo, llevando al formato de Turing a ocupar un lugar en nuestros bolsillos y convertirnos, primero en oficinas con patas gracias a Palm y RIM, y poco después en omnipresencias virtuales. Blackberry, Google, Twitter, Facebook y demás servicios online, eclipsan al todavía gigantesco Microsoft. Amazon se merienda el mercado editorial y Apple deja en ridículo a toda la industria audiovisual. Se abre una nueva era de desarrollo web (la Web 2.0 dicen, pero eso ya está obsoleto), servicios escalables, tratamiento masivo de datos personales, alta disponibilidad, integración... Y por si fuera poco, la informática y sus desarrollos se vuelven móviles con Nokia y Apple añadiendo nuevas tecnologías, nuevas técnicas y nuevos problemas para los desarrolladores.

Y nos plantamos al fin en Agosto de 2012. Los tablets han llegado para quedarse, ofreciendo una plataforma más interesante que los móviles si cabe, y con Microsoft apostando por ellos con un inesperado Windows 8 todoterreno: Móvil, Tablet, Escritorio. Un sistema tan bueno que estoy usándolo hoy mismo para trabajar contra los servicios cloud de Sharepoint y los servidores de mi oficina en ODM Computers, mientras escribo esto con la beta de Office 2013. Curiosamente aún está ahí el disquete para guardar el documento, aunque ahora lo haga directamente en Skydrive, el servicio de almacenamiento online de Microsoft (entre otras cosas).

La palabra mágica a desde hace unos pocos años, creo que es ecosistema. De poco sirve ya tener una aplicación específica corriendo en el servidor de un sótano como en los 40 o 70. Poco nos importa si el ordenador que tenemos es más o menos rápido como en los 80 o 90. La elección del sistema operativo no tiene demasiado impacto desde los 00’s aunque les pese a los fanboys de iOS y Android. Ahora lo que nos interesa es saber si podremos usar nuestro ordenador, Tablet o teléfono en casa, en la oficina y en la calle. Si nos dará problemas de compatibilidad con el Wifi, o si nos aportará algo al conectarlo a la tele, el coche o la red de ese Starbucks tan cómodo. Y saber si con él podremos sacarle todo el jugo a los servicios de la nube: Dropbox, Amazon, Youtube, Azure

Así que para ir acabando… el desarrollo de software ha pasado por muchas etapas en un periodo de tiempo muy comprimido y en cada una ha ido ganando complejidad, añadiendo capas de abstracción y mejorando todo lo existente anteriormente de manera fulminante (a ver quién se acuerda de Word Perfect, Altavista o Myspace). Y durante ese viaje, los desarrolladores hemos ido aprendiendo por las malas que cada problema es muy distinto y requiere distintas aproximaciones: calcular trayectorias balísticas, crear sistemas bancarios para grandes empresas, hojas de cálculo para pymes, editores de imagen para amateurs, sitios web para grupos privados… son cosas muy diferentes en casi todo. Pero no solo son problemas diferentes, sino que las herramientas para resolverlo han ido mutando y creciendo aceleradamente hasta formar una miríada de plataformas, estándares y personas que deben funcionar juntos.

Como desarrollador debo decir que ha sido un viaje alucinante. Pero lo mejor está aún por llegar. Por lo pronto tenemos un hito semejante al desembarco de Normandía en el mundillo tecnológico: Septiembre de 2012, Windows Reimagined. Por cortesía de Steven Sinofsky. Donde lo que presenta Microsoft no es solo un nuevo sistema operativo, sino un cambio de filosofía radical del que todos sus productos y servicios son partícipes. Y salga bien o mal, creo que es algo que voy a disfrutar.

FIN

*Según a quien preguntes y lo pesado que se ponga, puedes hablar de ábacos en el 2400 a.C. o telares programables en 1726, pero prefiero ceñirme a la idea común de ordenador o computadora que todos relacionamos con IBM, la NASA o Alan Turing.

viernes, agosto 17, 2012

Libro: Bajo presión


Título: Bajo presión. Cómo educar a nuestros hijos en un mundo hiperexigente.

Autor: Carl Honoré

Editorial: RBA



El título es algo engañoso. Honoré no nos va a decir como educar a nuestros hijos, aunque si hacemos caso a lo que cuenta, esa era su intención al iniciar la escritura de este libro.  Lo que sí hace Honoré es buscar y descubrir formas de educar a los niños, analizar qué parece funcionar y qué no, o incluso qué puede ser dañino. Y ya es bastante.

Puede que para algunos padres o interesados en el tema, esta obra sea algo novedoso, pero me temo que a mi me pilla un poco tarde. Ya creo (porque hablar de “saber” me parece absurdo venga de quien venga cuando hablamos de educación) que la educación es algo tremendamente complejo, con muchos intereses cruzados y opuestos de las comunidades de padres, profesores, editores, políticos… Entiendo que extraer conclusiones es terriblemente difícil dado que la educación es algo que abarca décadas, y también entiendo que la estadística solo funciona con números grandes, nunca con individuos. Así que gran parte de lo interesante del libro, me pilla un tanto de vuelta. Aun así está bien para reafirmarse, para ver como cosas que crees, son respaldadas por alguien con datos y mejor defendidas de lo que podría hacer uno mismo. Y es agradable ver durante el periplo de Honoré, que hay muchas iniciativas en marcha en el mundo para mejorar la educación y reducir la locura en la que se han convertido muchas sociedades y sistemas educativos.

Lectura altamente indicada para padres, educadores y personas relacionadas o interesadas con la formación y la educación pública y privada.

A continuación, algunos extractos:

Marilee Jones, ex docente a cargo de las admisiones en el MIT, observó que el campus había perdido parte de su brillo creativo. Concluyó que el proceso de admisión estaba descartando a los inconformistas, a las personas del estilo de Bill Gates, los rebeldes que persiguen una idea por sí misma en vez de complacer a los padres o a los posibles jefes.

-o-

Tal vez lo más sorprendente sea que los exámenes no constituyen ninguna prioridad en Finlandia. Aparte de los exámenes finales al término del instituto, los niños finlandeses no se enfrentan a exámenes estándar. Los profesores los ponen pruebas en sus respectivas áreas, y las escuelas comprueban la evolución de los alumnos, pero la idea de empollar para las pruebas de acceso a la universidad es tan ajena a Finlandia como una ola de calor en invierno. Ello plantea una deliciosa ironía: el país que pone menos énfasis en la competencia y los exámenes, que  muestra un menor interés por las escuelas preparatorias y las clases particulares, es siempre el primero del mundo en los competitivos exámenes de PISA.

Según Domisch Rainer, experto en educación alemán que ha vivido casi treinta años en Finlandia, esta paradoja se debe a que el sistema finlandés antepone las necesidades de los niños a los ambiciosos deseos de padres y burócratas.

-o-

Logramos buenos resultados generales porque atendemos a todos los estudiantes – dice Kassinen. La clave es que los chicos de todas las capacidades estén juntos en la misma clase: al fin y al cabo, así es la sociedad.

Los informes de la OCDE lo confirman: en los países que evitan la división de alumnos según sus aptitudes, hay mejores estudiantes.

-o-

Los maestros de escuela fineses tienen una tendencia excesiva al método de instrucción tradicional de pizarra y lección. Es extraño, si tenemos en cuenta su afición a la tecnología, pero los finlandeses tampoco se han apresurado a informatizar sus aulas.

-o-

Tal vez la lección más amplia es que no hay una fórmula mágica para mantener a los niños controlados, ni hace falta que la haya. Sólo hay que pensarlo un momento: ¿hay algo más espeluznante que un niño que se comporte de modo impecable en todo momento? ¿O una familia que nunca se pelee? Rebelarse contra la autoridad forma parte del crecimiento –todos lo sabemos instintivamente- y el conflicto es un rasgo de la vida familiar. Tal vez no resulte agradable que los niños estén enfurruñados, den portazos o digan entre dientes “Te odio”, pero eso es parte del trato paterno filial.

-o-

Después de que los románticos entronizaran la idea de la inocencia infantil, el miedo a la corrupción no cesó de intensificarse. Los críticos advirtieron que leer cómics estimularía en exceso a los jóvenes y los llevaría a cometer crímenes y actos disolutos. Otros temían que el trabajo en las fábricas de la Revolución Industrial mancillaran moralmente a los niños, lo que motivó que algunos jefes contrataran a monjas o enfermeras para tranquilizarse la conciencia. Como todos los demás miedos sobre la infancia, el temor a la corrupción aumentó en el siglo XX, y se amplió hasta abarcarlo todo, desde la música rock a tiendas de regalos.

Esto nos muestra una de las paradojas más curiosas de la infancia moderna: hoy, al mismo tiempo que nos inquieta nuestra pérdida de inocencia, permitimos, incluso alentamos, que los niños se mojen cada vez más temprano los dedos en la piscina adulta. En parte se debe a nuestro deseo de acercarnos a los hijos, de fortalecer el estatus de “mejor amigo”. Al fin y al cabo, nada une más a dos personas que un pasatiempo compartido. Sólo hay que oír cómo deliran algunas madres sobre hacer limpiezas de cutis y pedicura a sus hijas de nueve años.

-o-

Claro está que el papel de los padres sólo es una parte de la ecuación. Más allá de la familia, debemos replantear las normas que gobiernan todo lo tocante a las vidas de los niños: escuela, publicidad, juguetes, deportes, tecnología, tráfico. Eso implica aceptar algunas verdades incómodas: que los coches deben ocupar menos espacio en nuestras calles, que gran parte del mejor aprendizaje no puede medirse, que los chismes electrónicos no pueden reemplazar algunas cosas, que la medicación debe ser el último recurso ante un comportamiento difícil, que nuestra adicción colectiva al consumo debe acabar.

martes, agosto 14, 2012

El abismo




Como desarrollador con unos cuantos proyectos a mis espaldas, he llegado a identificar como uno de los problemas más importantes a resolver lo que llamamos "gap" tecnológico del usuario. ¿Qué este gap tecnológico? Pues se trata de la falta de determinados conocimientos tecnológicos (del usuario o cliente), que imposibilitan la comprensión y uso de un sistema.

Esta tierra de nadie, esta zanja en el camino a la solución tecnológica, puede ser de distintos tamaños, yendo desde la simple ignorancia de un pequeño truco o utilidad como puede ser el usar el TeclaControl+F para buscar palabras en un documento, o el TeclaWindows+escribir para encontrar una aplicación en sistemas Windows 7/8, a algo mucho más profundo y peligroso como puede ser la total falta de conocimientos no ya en informática (que al fin y al cabo solo existe masivamente desde hace unos 50 años) sino la más completa ignorancia sobre qué es un automatismo, ordenador o máquina.

Con esto quiero decir que en casos leves es solución suficiente señalar al usuario dónde está un menú, o hacerle una demo de una funcionalidad nueva, pero en demasiadas ocasiones nos encontramos ante la ausencia del marco necesario para entender un carajo.

Este caso sería el del típico empleado que guarda toda su información en su ordenador local, y desconoce lo que es un fallo de hardware, una copia de seguridad, la naturaleza electromagnética de la información de su disco o RAM (volátil), las soluciones gratuitas de backup local y online, el valor de su información, etc…

Este tipo de usuarios puede ser un auténtico problema en entornos informatizados (cualquier oficina de más de 2 personas a día de hoy) por varias razones:

1.      Por un lado su falta de conocimientos hace que use mal las herramientas, en general infrautilizándolas y perdiendo un montón de tiempo al cabo de día por ello.

2.      Por otro lado, todo ese tiempo malgastando es tiempo que alguien tiene que pasar esperando o se transforma en trabajo extra para otros compañeros (por baja productividad o control de daños).

3.      La frustración que produce usar mal las herramientas lleva al usuario a estar descontento con las herramientas y eso genera una carga negativa a día a día que puede sumarse a otras cosas para generar un mal ambiente de trabajo.

4.      La lentitud y complejidad extra añadida al trabajo por un mal uso de la herramienta, suele  pasar factura a la concentración del trabajador, empeorando sus resultados.

5.      La imagen de la tecnología y los cambios, se ve empañada a ojos del usuario por todo lo anterior, generando una animadversión a la tecnología y el cambio. Algo que a la larga puede matar a una empresa o industria al completo.

Por si todo esto no fuera ya bastante malo, resulta que la llamada brecha digital solo se amplía con el tiempo y llega un punto en que se hace tan grande que tratar de superarla uno mismo cuesta mucho más de lo que podemos asumir, en particular en condiciones de estrés y negatividad como las que enumeraba antes. Y en cuanto a confiar en terceros…  reconozcámoslo: la mayoría de los cursos de formación tecnológica tienen mucho de estafa (ofertas de pocas horas concentradas, malos docentes, programas rígidos…) o un desastre por falta de tiempo (RRHH contratando basurilla y presionando para abaratar algo con que llenar el expediente).

Es por todo esto que el gap tecnológico, la brecha no tanto digital como tecnológica, es tan peligrosa: provoca problemas reales, reduce la productividad, aumenta con el tiempo, se contagia a su alrededor y no existe una solución definitiva para ella.

Así que ahora que sabemos qué es y cómo nos afecta, preguntareis “¿cómo arreglamos este gap, este abismo de conocimientos que está cargándose la viabilidad de mi empresa?” La respuesta es, en mi opinión, que no se puede resolver, solo podemos tratar de minimizar el problema. Y para minimizarlo, al margen de reconocerlo en nosotros (sí, todos lo tenemos, no se libra ni Dios) y en los demás, debemos tratar de atacarlo a la mínima oportunidad: si vemos que nuestros compañeros desconocen algo o realizan tareas que debería estar realizando una máquina, debemos acercarnos y ayudar con ello. Se requieren también paciencia, curiosidad y humildad para reconocer nuestra propia ignorancia y ocasional estupidez. Y se requiere una voluntad de equipo para tratarla entre todos en el día a día, a pesar del estrés, los roces y los humos de cada uno de nosotros. Pero sobre todo, creo que se requiere valor y asertividad para cuestionarlo todo (independientemente de la jerarquía) y disentir públicamente.

¿Difícil? Sí. ¿Incómodo y desagradable en muchos casos? Desde luego. Pero la alternativa dada la velocidad de los acontecimientos, es el fracaso a medio y largo plazo. Y si no, que se lo digan a la industria musical (barrida por iTunes y el P2P), la industria del cine (barrida por Megaupload y los torrents) o la industria editorial (barrida por Amazon y los ebooks) entre otras afectadas por no tener un marco de conocimientos adecuado sobre la tecnología y las herramientas.

Lecturas relacionadas MUY recomendables: Philip Zimbardo, Gerd Gigerenzer, Usuarios del siglo XXI, Robert J. Stenberg.

jueves, agosto 02, 2012

Ya.com y sus regalos

Durante unos cuantos años fui un cliente de Ya.com más o menos satisfecho. Pura suerte, ya ven. Pero con el paso del tiempo, las prácticas de telemarketing de dudosa ética y legalidad y los comportamientos irregulares de lo que pensaba era la línea, acabé pasándome a Jazztel.


El caso es que el teléfono fijo e inalámbrico que uso en casa, fue parte del kit de bienvenida que ofertaba Ya.com hace unos tres años, y el otro día le dio por cascar. La pantalla de cristal LCD dejó, de un día para otro, de mostrar información más allá de unas rayas que hacían poco usable el terminal. Como me gusta tratar de arreglar las cosas y me tomo tiempo y cuidado cuando puedo, me dio por destripar el aparato con la esperanza de poder repararlo, antes de tomar la decisión de comprar uno nuevo. Y en esa operación descubrí algo inquietante.


El terminal parece que sufrió algún fallo y fue reparado por algún herrero, a la luz del estado de los componentes. Una chapa levantada, posiblemente para soldar algo de circuitería, y vuelta a poner en su sitio con los dientes por lo menos. Tras la hazaña de herrero de taller clandestino, le debieron poner la pegatina de refurbished, y acabó en un lote de bienvenida de Ya.com. En mi casa. Y cascando.


Así que amigo lector, si tienes problemas en casa con tu ADSL de Ya.com, recuerda que es más que probable que el problema sea del material de mercadillo que te entregaron y que supusiste que sería barato, pero no barato además de defectuoso.


Ah, y comprueba los microfiltros. Me dicen que a veces esos cabrones fallan.


Por si alguien tiene curiosidad tecno-morbosa, adjunto las fotos del trabajo herreril del proveedor de Ya.com. Véase el machaque de la chapa de la pegatina verde:









PD: El teléfono se recuperó bien una vez desmontado el LCD, limpiado la zona, vuelto a colocar las conexiones en su sitio y aplicado presión a base de silicona.


PD2: Jazztel bien, gracias. Aunque parece que mi oscuro pasado con Vodafone (con quienes no volvería ni cobrando) les pone un poco nerviosos a la hora de dejarme contratar móviles. Peor para ellos. Yoigo va muy bien.





Educando con el ejemplo

A los niños hay que enseñarles a apreciar las cosas buenas de la vida. Cómo el Doctor Who.


miércoles, julio 18, 2012

Libro: Piano. La historia de un Steinway de gran cola


Titulo: Piano. La historia de un Steinway de gran cola.
Autor: James Barrow 
Editorial: Alba 




Qué pasada de libro.

Imagino que no todo el mundo lo verá así, pero para mi, leer esta obra está al nivel de catarsis tras años de clases de piano practicamente olvidadas (más por imposibilidad de practicar que por desgana). Ha supuesto volver a escuchar las obras de Beethoven, Bach, Tchaikovsky o Rachmaninov con un interés adicional y un conocimiento orgánico del instrumento en si y de su historia (sin ser más que aficionado, ojo). Y ha supuesto volver a avivar con mi interés de la niñez por dos fabricantes de instrumentos: Steinway y Stradivari.

Puede que a quien no haya estudiado piano, o a quien no le interesan la fabricación (diseño, avances técnicos…) de instrumentos (no solo los musicales) no le parezca una obra tan buena, pero desde luego, es una buena obra. De ello se encarga James Barrow (perfectamente traducido), que transpira calidad al narrar el relato, ejerciendo como dios manda el oficio de periodista.

Retrospectivamente, es posible que leer este tipo de obras (aun tengo pendiente la reseña del de violín) me hubiesen animado más y mejor en el aprendizaje de un instrumento, pero esa historia ya es agua pasada, y a día de hoy su lectura me anima a educar en lo musical y en lo científico/técnico a mi hija. Así que si eres un nuevo estudiante de música (no exclusivamente de piano), un viejo aficionado, un fan de la música clásica, un fabricante de herramientas (desarrolladores de software incluidos), o incluso un aspirante a empresario, deberías leer este libro.

El siglo de historia que narra, nos acerca, no solo a la fabricación de un instrumento de precisión moderno, sino a la historia de una empresa, la de los cambios tecnológicos y económicos acaecidos, y la relación del hombre, del especialista, con sus herramientas.

Como hay más y mejores críticas en lugares como Amazon http://www.amazon.com/Piano-Making-Steinway-Concert-Grand/dp/0805078789 , lo dejaré aquí, solo para recomendarlo encarecidamente y para poner las habituales citas interesantes.


La RCA comercializaba la marca de radios más vendida en la nación y Sarnoff comprendió lo que podían ofrecer: entretenimiento con solo girar un botón… No hacían falta ni clases ni talento y las radios eran más baratas que los pianos, que los Steinway en particular. [Tras haber sobrevivido al fonógrafo y al tocadiscos…] en 1933 dos terceras partes de los hogares estadounidenses tenían receptor de radio.
-o-
Incluso los clientes que querían comprar un piano de cola no querían modelos grandes. Las casa adosadas iban desapareciendo en Nueva York y, en su lugar, surgían edificios de apartamentos. Henry Z. Steinway nación en un piso del edificio que se erigió en el solar de la Cuarta Avenida que ocupaba la primera fábrica Steinway. Lo que mantuvo a Steinway & Sons cuando la gente tuvo que conformarse con viviendas más pequeñas que las casas adosadas de sus padres fue el modelo M, un piano de cola que empezó a fabricarse en 1912 y que medía un metro menos que los gran cola como el K0862 (el protagonista del libro, un modelo D).
-o-
El problema de los pianos es que son orgánicos y cambian constantemente. No tienen nada que ver con la fabricación de neveras y cosas así.
-o-
[Acerca del ajuste de cuerdas en el piano] Utiliza una herramienta que tiene una especie de gancho al final y tira con fuerza. “Algunos llevamos pinzas de médico, de las que usan para cortar hemorragias, que parecen unas tijeras largas”, dice. Se refiere a las pinzas de hemostasia; algunas tienen dientes en los filos y vienen muy bien para tirar de las cuerdas.

lunes, julio 02, 2012

Code as Design: Three Essays by Jack W. Reeves





Por alguna razón tengo en la recámara desde hace meses una versión alternativa del artículo sobre La programación como proceso de diseño. Y como creo que es bastante diferente del "original", además de que siempre es buena idea hablar sobre desarrollo de software, lo añado a continuación. 

:-)

Code as Design: Three Essays by Jack W. Reeves

Estos ensayos con casi veinte y diez años de antiguedad, siguen siendo una verdad como un templo y comenta cosas que la mayoría de las personas en el mundo del software, ignoran (y olvidamos) con consecuencias negativas a corto, medio y largo plazo.

El punto clave del ensayo es que desarrollar código, es un proceso de diseño, y es uno muy complicado.

Siempre se compara el desarrollo de software con otras ingenierías donde se diseña y construye algo físico. Pero es incorrecto. Si hacer aviones se pareciese a hacer software, entonces pulsando un botón, los planos y especificaciones de un Boeing 747 se convertirían en un avión real y en pleno vuelo en cuestión de segundos o minutos a coste cercano a cero. Si se tratase de hacer puentes, el F5 nos permitiría levantar un puente para comprobar cuanto peso aguanta con pilares de un material u otro en el mismo tiempo y al mismo coste.

La naturaleza de las ingenierías "normales" es construir algo en base a unas especificaciones. Algo caro de diseñar, pero muchisimo más caro de construir (tiempo, recursos, gente). En software la "build", es decir el producto final construido, es cuestión de un compilador y un par de minutos (o segundos). Lo realmente caro es el diseño, y el diseño (especificaciones, planos...) es el código. Construir en base al diseño es labor del compilador y al contrario que en todas las demás ingenierías, tiene un coste en tiempo y dinero cercano a cero.
Partiendo de esa premisa, es fácil de donde vienen ciertos problemas, como las especificaciones mutantes, el scope creep, etc.

A continuación dejo algunas citas interesantes.

Revelation number two: it is cheaper and simpler to just build the design and test it than to do anything else. We do not care how many builds we do—they cost next to nothing in terms of time, and the resources used can be completely reclaimed later if we discard the build. Note that testing is not just concerned with getting the current design correct, it is part of the process of refining the design. Hardware engineers of complex systems often build models (or at least they visually render their designs using computer graphics). This allows them to get a "feel" for the design that is not possible by just reviewing the design itself. Building such a model is both impossible and unnecessary with a software design. We just build the product itself. Even if formal software proofs were as automatic as a compiler, we would still do build/test cycles. Ergo, formal proofs have never been of much practical interest to the software industry.
-o-
The overwhelming problem with software development is that everything is part of the design process. Coding is design, testing and debugging are part of design, and what we typically call software design is still part of design. Software may be cheap to build, but it is incredibly expensive to design. Software is so complex that there are plenty of different design aspects and their resulting design views. The problem is that all the different aspects interrelate (just like they do in hardware engineering).
-o-
[...] no other modern industry would tolerate a rework rate of over 100% in its manufacturing process. A construction worker who can not build it right the first time, most of the time, is soon out of a job. In software, even the smallest piece of code is likely to be revised or completely rewritten during testing and debugging. We accept this sort of refinement during a creative process like design, not as part of a manufacturing process. No one expects an engineer to create a perfect design the first time. Even if she does, it must still be put through the refinement process just to prove that it was perfect.
-o-
The software design is not complete until it has been coded and tested. Testing is a fundamental part of the design validation and refinement process. The high level structural design is not a complete software design; it is just a structural framework for the detailed design.
-o-
It would be nice if high level software design could be a more rigorous engineering process, but the real world of software systems is not rigorous. Software is too complex and it depends on too many other things. Maybe some hardware does not work quite the way the designers thought it did, or a library routine has an undocumented restriction. These are the kinds of problems that every software project encounters sooner or later. These are the kinds of problems discovered during testing (if we do a good job of testing), for the simple reason that there was no way to discover them earlier. When they are discovered, they force a change in the design. If we are lucky, the design changes are local. More often than not, the changes will ripple through some significant portion of the entire software design (Murphy's Law). When part of the effected design can not change for some reason, then the other parts of the design will have to be weakened to accommodate. This often results is what managers perceive as "hacking", but it is the reality of software development.
-o-
As just a small point, all programmers know that writing the software design documents after the code instead of before, produces much more accurate documents. The reason is now obvious. Only the final design, as reflected in code, is the only one refined during the build/test cycle. The probability of the initial design being unchanged during this cycle is inversely related to the number of modules and number of programmers on a project. It rapidly becomes indistinguishable from zero.
-o-
The generally accepted definition is that a “specification” states the what, which is followed by a design document that details the how. While there is a certain amount of flexibility allowed of the compiler in determining the how of object code, there is certainly no creativity involved. And that is where I draw the line. When the document is detailed enough, complete enough, and unambiguous enough that it can be interpreted mechanistically, whether by a computer or by an assembly line worker, then you have a design document. If it still requires creative human interpretation, then you don’t.
-o-
Back to software. We in the software industry also refine our designs, only we don't get to call it engineering. We call it "testing and debugging". This phase of the software lifecycle takes a long time. All too often it takes longer than planned. Unfortunately, it is often not enough and the final designs that we turn into deliverable software are still not as good as they should be. This seems like a fact of software life. Many people lament it and ask why we software developers do not "engineer" our designs better? Many explanations are offered, but never the one most obvious to me -- simple economics. Software is dirt cheap to build.
-o-
I suspect that most engineers in other disciplines haven't a clue about what percentage of their time is spent actually creating a design and what is spent on testing and debugging the result. Some industries are probably better than software. I am pretty sure that other industries are actually much worse. Consider what it must take to "design" a new airliner.
-o-
I get somewhat testy when people start making gratuitous comparisons between software design and other engineering disciplines. Major microprocessors have been shipped with bugs in their logic, bridges have collapsed, dams broken, airliners fallen out of the sky, and thousands of automobiles and other consumer products recalled - all within recentmemory and all the result of design errors.
-o-
The bottom line is that my design must be correct, or every piece of software built from it will be erroneous. Therefore I concentrate on doing it right, and it takes mental effort and skill, just like any other creative design activity.
-o-
Even the best of the traditional approaches continue to try to break software design into disjoint steps with separate notations and products, and then they continue to wonder why they have problems getting a final software product that is correct.
-o-
Same thing. Likewise, Warner-Orr diagrams, Booch diagrams, object diagrams, you name it. Each has its strengths, and a single fundamental weakness - it really isn't a software design. Ultimately, improvements in programming techniques are overwhelmingly more important to software development than anything else.

Libro: Matar a un elefante




Titulo: Matar a un elefante
Author: George Orwell
Editorial: Turner

"Matar a un elefante" es una crónica de Orwell de cuando servía a Su Majestad en la India. Y es la crónica que muy acertadamente da nombre a este conjunto de artículos y crónicas del escritor aglutinadas en formato libro.

No se trata de un libro especialmente interesante, pero dada la variedad de textos y el intervalo temporal que abarcan, puede resultar suficientemente interesante para los admiradores de Orwell que quieran saber algo más de el como pensador de su época y no solo como escritor de ficción (si no has leído 1984 y Rebelión en la Granja, ya estás tardando).

A mi en particular me ha parecido bastante prescindible, a excepción del primer relato, el del elefante que tiene que sacrificar (o ejecutar, según se mire) bajo la opresiva mirada de los aldeanos y que da que pensar sobre la importancia del entorno y las circunstancias en los actos de cada uno, muy al estilo de Philip Zimbardo en El Efecto Lucifer. El resto de capítulos creo que me los podría haber ahorrado, aunque no está de más leer sus opiniones sobre la Segunda Guerra Mundial y la Guerra Civil Española (la del 34).

A continuación, algunos extractos de muestra:


[Sobre la Guerra Civil Española] Los fascistas ganaron la guerra porque eran más fuertes. Disponían de armamento moderno que el otro bando no poseía. No hay estrategia política que pueda paliar tal deficiencia.

-o-

Los llamados dominios de habla inglesa [...] son rehenes que están en manos de Norteamérica. Por lo tanto, siempre existe el poligro de que Estados Unidos rompa toda coalición europea, arrastrando a Gran Bretaña fuera de ella.

-o-

Los pueblos de Europa, y en especial los británicos, desde hace mucho deben su elevado nivel de vida a la explotación directa o indirecta de los pueblos de color, Esta es una relación que nunca se ha aclarado debidamente en la propaganda oficial del socialismo, y el trabajador británico, en vez de recibir el mensaje de que, según la media mundial, vive por encima de sus posibilidades, ha sido aleccionado para pensar que es un esclavo que trabana en exceso y que está pisoteado por el patrón. Para las masas, el "socialismo" significa o al menos se relaciona con salarios más altos, jornadas laborales más cortas, viviendas mejores, seguridad social para todos, etc. Ahora bien, de ninguna manera es seguro que sea posible financiar tales ventajas si se prescinde de los beneficios que acarrea la explotación colonial.

jueves, enero 19, 2012

Lecciones aprendidas en 2011




Este es un recopilatorio de lecciones aprendidas por las malas en el 2011 que fui poniendo en Twitter desde Mayo con el hastag #LeccionesAprendidas

Las dejo aquí (la mayoría al menos) para poder localizarlas fácilmente, ya que Twitter no es la mejor manera de guardar información que quieras usar.

Ah y un aviso, deben ser leídas con la mente abierta. No se trata de quejas, chistes, o cabreos del momento, sino de ideas meditadas, experiencias que me han dado que pensar y que querría recordar en el futuro.

Si alguien quiere añadir alguna, estaré atento a los comentarios. :-)

#LeccionesAprendidas:

No se puede agradar a todo el mundo. Al final hay que toma elecciones y hacer lo que uno crea mejor.
Fri Jan 06 12:25:25 +0000 2012 
Si te envían un correo con más de una dirección en el "Para:", ignóralo. Es un intento de colocar un marrón.
Mon Oct 31 17:12:39 +0000 2011 
Nunca es fácil. Nunca.
11:31 AM Oct 18th from web 
Cuando necesites tener tiempo para ti, tómatelo, porque nadie más te lo va a dar.
9:26 PM Oct 9th from Twitter for Android 
Do less to achieve more and be happier. No excuses.
8:37 AM Oct 8th from web 
Si mezclas tónica Qtonic con ginebra Gin Mare, te cargas el #gintonic.
4:48 PM Aug 15th from web 
Cuando suficiente gente sigue instrucciones sin entender su sentido final o pervirtiéndolo, se crean problemas gordos.
4:01 PM Aug 8th from Twitter for Android 
El Excel puede ser tu mejor amigo a la hora de tratar datos de listas y bibliotecas.
11:30 AM Jul 12th from web 
Las personas están sobrevaloradas.
8:53 PM Jul 3rd from Twitter for Android 
Cuando trabajes con #Sharepoint, procura que todo lo que instales en una misma máquina, esté en el mismo idioma.
2:54 PM Jun 29th from web 
Cuando hay tiempo para pensar, y se usa para ello, todo va mucho mejor. #soluciones
5:22 AM Jun 16th from Twitter for Android 
Eat your own dog food. Pero realiza catas de la de los demás, de vez en cuando.
3:06 PM Jun 15th from web 
Sharepoint #onpremise#online es un sistema demasiado grande, complejo, y cambiante como para llevarla en solitario.
5:37 PM Jun 8th from Twitter for Android 
A nadie le gusta asumir la derrota. Pero la alternativa es el desastre total.
6:21 PM Jun 7th from Twitter for Android 
A veces, arrastrarse, culpar a un chivo expiatorio y decir que sí a todo, puede ser la única estrategia efectiva.
5:50 PM Jun 7th from Twitter for Android 
Nunca confíes en un comercial. Sin excepción.
5:43 PM Jun 6th from Twitter for Android 
Es mucho mejor conocer las preguntas correctas, que tener buenas respuestas.
6:06 AM Jun 6th from Twitter for Android 
No juzgues a personas u organizaciones por lo que dicen o consiguen. Observa atentamente lo que hacen.
1:32 PM Jun 3rd from Twitter for Android 
Normalmente la parte más complicada e importante de resolver un problema es entender cual es el problema.
9:00 AM Jun 3rd from web 
Si tienes que dejar tu máquina de trabajo funcionando tras la jornada, es evidente que ahí tienes un cuello de botella.
5:46 PM Jun 2nd from Twitter for Android 
En 1 proyecto informático, suele haber 2 problemas a resolver: el real y el percibido. Con soluciones incompatibles.
6:15 PM Jun 1th from Twitter for Android 
A menudo veo soluciones rechazadas por "malas", que acaban demostrando ser soluciones excelentes pero mal entendidas.
6:08 PM Jun 1th from Twitter for Android 
Hacer horas extra no compensa. Huir de ellas como de la peste o exigir enormes recompensas inmediatas si no queda otra.
12:22 PM Jun 1th from web 
Pasar por y recuperarte de, una experiencia horrible, cambia la manera en que se ven y juzgan las cosas.
5:47 PM May 31st from Twitter for Android 
Hay muy poca gente con vocación por su trabajo (algunos la pierden, otros nunca tuvieron). Y son los más valiosos.
5:26 AM May 31st from Twitter for Android 
La gente no cambia nunca, ni siquiera un poco. Solo cambian las circunstancias.
5:25 PM May 30th from web 
Las limitaciones pueden ser una ayuda... cuando el objetivo está perfectamente claro.
5:12 PM May 29th from web 
Los eufemismos siempre esconden problemas. Para resolver un problema (si ese es el objetivo) lo primero es eliminarlos.
6:40 PM May 28th from web 
Por muy bueno que sea, nadie se suma a un plan si no lo conoce o no le convence. Se necesita contar con evangelistas.
2:47 PM May 27th from Twitter for Android 
El trabajo en equipo requiere reglas y objetivos, claros y conocidos. Comunicacion y trasparencia al fin y al cabo.
2:36 PM May 27th from Twitter for Android 
El trabajo que Mr X no hace, lo acaba teniendo que hacer Mr Y. Donde Mr Y suele ser un servidor.
9:34 AM May 26th from web 
Escucha lo que la gente tenga que decir, pero dale mucha más importancia a lo que hacen.
5:49 AM May 25th from Twitter for Android 
Madurar supone no solo asumir responsabilidades, sino también decidir y actuar en base a ellas.
10:24 PM May 24th from Twitter for Android 
El desarrollo de Software es un proceso de diseño. Recalco "proceso".
5:29 AM May 24th from Twitter for Android 
Algunas personas no tienen alegría por vivir. Y lo único que puede hacerse al respecto es no ser arrastrados por ellos.
5:28 AM May 24th from Twitter for Android 
Decir no. Que no, coño.
5:54 PM May 23rd from Twitter for Android 
A menudo la gente solo tiene razones emocionales xa tomar decisiones. Mencionarles razones objetivas solo les cabreará.
6:21 AM May 20th from Twitter for Android 
La gente confunde "trabajo en equipo" con "asignar trabajo". Y confunde "equipo" con "individuos en una habitación".
6:15 AM May 20th from Twitter for Android 
Sin trabajo en equipo, el rango de problemas al que se puede uno enfrentar es tendente a 0.
6:14 AM May 20th from Twitter for Android 
No hay balas de plata. Nunca las hay. Y quien dice tenerla suele ser un tonto, o un iluminado camino del desastre.
8:56 PM May 15th from web 
Algunas personas prefieren los rumores y los prejuicios, a la información de 1a mano y los hechos comprobables.
6:32 PM May 11th from Twitter for Android 
Algunas personas piensan que el tiempo de los demás no vale nada.
6:28 PM May 11th from Twitter for Android 
La formación continua y mantenerse al día es importante y DEBE hacerse principalmente en horario laboral.
7:49 PM May 8th from web 
Multitud de pequeñas mejoras en las herramientas, entorno, técnicas y organización; producen grandes diferencias.
9:09 PM May 4th from Twitter for Android 
Olvidar lo aprendido es tan importante y necesario como haberlo aprendido en primer lugar.
7:12 PM May 4th from web 
Un trabajador feliz es MUCHO más productivo.
7:11 PM May 4th from web

miércoles, enero 18, 2012

La programación como proceso de diseño (Code as Design)




Hace unos meses que tengo pendiente comentar un poco los ensayos de Jack W. Reeves: Code as Design.

Se trata de unos textos realmente valiosos dada su relevancia a lo largo de dos décadas (el primero fue publicado inicialmente en 1992) y por la peculiaridad de que la idea fue revisada 13 años después. Pero además es decepcionante ver como aun hay muchos profesionales del sector que no tienen claro lo que comentaba Reeves ni nada remotamente parecido.

La idea central que plantea Reeves es simple en su formulación: el desarrollo de software es un proceso de diseño. Pero esa simpleza oculta multitud de ideas interesantes y de prejuicios dentro y fuera del sector que llevan a considerar al programador como un obrero más. Y así nos va.

Esa idea nos lleva a plantear la obligatoriedad de que los cambios de requisitos deberían ser caros. Y que los desarrolladores ni son albañiles, ni son intercambiables como les gusta pensar a las grandes consultoras. O que el presupuesto cerrado a la hora de entregar un software es una estupidez de base. Pero como es un ensayo corto y discutido a lo largo de 20 años, creo que será mejor que cada uno lo lea (es corto) y juzgue por sí mismo.

A continuación para tratar de animar a los mas perezosos a leerse los ensayos, pongo algunas citas interesantes:

The Unpredictability of Requirements
There's a refrain I've heard on every problem project I've run into. The developers come to me and say "the problem with this project is that the requirements are always changing". The thing I find surprising about this situation is that anyone is surprised by it. In building business software requirements changes are the norm, the question is what we do about it. 
One route is to treat changing requirements as the result of poor requirements engineering. The idea behind requirements engineering is to get a fully understood picture of the requirements before you begin building the software, get a customer sign-off to these requirements, and then set up procedures that limit requirements changes after the sign-off. 
One problem with this is that just trying to understand the options for requirements is tough. It's even tougher because the development organization usually doesn't provide cost information on the requirements. You end up being in the situation where you may have some desire for a sun roof on your car, but the salesman can't tell you if it adds $10 to the cost of the car, or $10,000. Without much idea of the cost, how can you figure out whether you want to pay for that sunroof? 
Estimation is hard for many reasons. Part of it is that software development is a design activity, and thus hard to plan and cost. Part of it is that the basic materials keep changing rapidly. Part of it is that so much depends on which individual people are involved, and individuals are hard to predict and quantify. 
Software's intangible nature also cuts in. It's very difficult to see what value a software feature has until you use it for real. Only when you use an early version of some software do you really begin to understand what features are valuable and what parts are not. 
This leads to the ironic point that people expect that requirements should be changeable. After all software is supposed to be soft. So not just are requirements changeable, they ought to be changeable. It takes a lot of energy to get customers of software to fix requirements. It's even worse if they've ever dabbled in software development themselves, because then they "know" that software is easy to change. 
But even if you could settle all that and really could get an accurate and stable set of requirements you're probably still doomed. In today's economy the fundamental business forces are changing the value of software features too rapidly. What might be a good set of requirements now, is not a good set in six months time. Even if the customers can fix their requirements, the business world isn't going to stop for them. And many changes in the business world are completely unpredictable: anyone who says otherwise is either lying, or has already made a billion on stock market trading. 
Everything else in software development depends on the requirements. If you cannot get stable requirements you cannot get a predictable plan.

En serio. Si no lo has leído, léelo ya.

martes, enero 17, 2012

Problemas desenfocados




Como desarrollador, en muchas ocasiones tengo la ocasión de observar lo que solo se me ocurre llamar "problema de enfoque". Cosas (a menudo soluciones propuestas al cliente) que vistas desde cierta perspectiva o distancia, parecen problemas, pero que en realidad no lo son, y que a menudo se deben a un fallo de comunicación (ya sea por parte del proveedor o del usuario, por falta de conocimientos, intereses ocultos, etc.).

En esas situaciones, cuando el usuario percibe algo como un error (que no lo es bajo ningún parámetro racional), corregir el error percibido puede ser inútil, costoso y/o contraproducente. Y en esos casos la acción encaminada a solucionar el error percibido debe aplicarse en primer lugar sobre la comunicación (lenguaje común, metáforas, demostraciones...) y sobre el usuario (formación, pruebas, laboratorios, extraerle mediante tortura los verdaderos motivos de la solución informática...).

En psicología, si no recuerdo mal, suele hablarse de este problema bajo los términos: "marco", "contexto", "error cognitivo", "conducta automática o irreflexiva" o "prejuicio". Y en el mundillo de las TIC hay un chiste relacionado con el tema: "no es un bug, es una feature". Sea como fuere, se trata de algo muy común, y que poco tiene que ver con la tecnología, aunque sí con la informática según la concepción de Dijkstra de "resolver los problemas de la gente [...] entender a la gente".

En el ámbito del software, suelo observar este problema en clientes que no entienden la tecnología, su área de negocio (más habitual en grandes empresas) o ambos (motivo de extinción para muchas empresas en el pasado). Y dependiendo de a quién le preguntes obtendrás apoyos diferentes en cuanto a si solucionar el problema real o solo dedicarse al percibido por el cliente (raro es que quieran una solución completa). La analogía médica sería que ante una enfermedad tuviésemos que elegir entre tratar de curar al paciente mediante un tratamiento incómodo que debemos explicarle y para el que necesitamos de su cooperación, o limitarnos darle un placebo que le haga sentir bien y mandarle a casa. Obviamente habrá casos graves y leves que podrán inclinar la balanza pero en general no me gusta en absoluto tirar de placebo.

Además puede pasar que el cliente sufra de pánico cuando observa el problema (el percibido) y se cierre en banda en cuanto a la solución, adoptando una mala solución técnica que aporte poco o nada a su negocio. Si a eso le sumamos un comercial centrado exclusivamente en vender (no en aportar una solución) que apoye al 110% la solución del cliente, ya tenemos un coctel explosivo ante el cual el consultor y/o desarrolladores pueden, o bien ceder para contentar temporalmente al cliente (que puede y suele acabar dándose cuenta de que necesita una solución mejor), o  bien tratar de hacerle notar el problema de enfoque a base de paciencia, mano izquierda, mucha formación y tiempo. Cada una de estas posturas tiene pros y contras, por lo que no hay balas de plata. Como en la analogía del médico y el placebo, en ocasiones lo mejor sería coger el dinero y hacer lo que el cliente pide (fácil pero en mi opinión bastante rastrero y cortoplacista), y en otras lo mejor es hacer lo que el cliente necesita y presentárselo (arriesgado según el tipo de cliente) para que lo pruebe antes de aceptar o denegar la solución (las veces que he tenido ocasión de hacerlo, ha funcionado y a permitido establecer una relación de confianza con el cliente).

Así que tenemos un problema que puede identificarse y abordarse, pero requiere habilidades no técnicas, o al menos no según una concepción conservadora del mundillo. Y como es un problema común y persistente, no es extraño que se hayan pensado y probado con éxito cosas como el desarrollo ágil, para abordarlo (al menos parcialmente, dado que ágil significa muchas cosas). Pero eso es otra historia.

Resumiendo: la informática es mucho más que programar o hacer productos excelentes, los desarrolladores no somos infalibles, los comerciales pueden ser un problema, y el cliente no siempre tiene razón, aunque a menudo haya que dársela. Nada nuevo bajo el sol, lo sé, pero espero que el recordatorio le sirva a alguien a parte de mi mismo.



lunes, enero 16, 2012

Directivos psicópatas: Un problema ignorado. Una propuesta de solución.




Al hilo de las declaraciones del artículo del diario británico Independent (muy, muy recomendable), me gustaría retomar brevemente el tema de los psicópatas y los puestos de responsabilidad y decisión (AKA: directivos).

Que los psicópatas orgánicos (nacidos así) y funcionales (que se comportan como tal, que aprenden a serlo) están ahí es un hecho indiscutible, y con el tema de la crisis su presencia y acciones están quedando al descubierto en los casos más sangrantes. Es más, al parecer son sus acciones las que nos han traído hasta aquí, hasta los 5 millones de parados, los recortes y la bancarrota de cajas y comunidades autónomas.

No merece la pena entrar a enumerar los gravísimos problema que causa (no es una posibilidad sino un hecho muy real) tener a uno o varios psicópatas en un organigrama empresarial o social. Sin mirar la historia o los periódicos podemos imaginar una degradación de las relaciones, un maltrato del cliente, o incluso el amañado de cuentas y desfalcos con resultados catastróficos. Pero no pensemos que esto son ideas difusas, los psicópatas funcionales y orgánicos están ahí, están haciendo mucho daño y no deben ser tolerados.

Por eso, por tratar de controlarlos y mejorar nuestras empresas, sociedades y el mundo en general, me gustaría que el lector reflexionase sobre la necesidad de establecer controles de acceso a los puestos de responsabilidad para evitar que los psicópatas acaben en ellos.

Identificarlos es el primer paso tanto para curar a los psicópatas funcionales, como para vigilar estrechamente o marcar a los orgánicos que necesiten ser degradados, despedidos o medicados, dependiendo del caso. Y la identificación permitiría dos medidas clave: relevar a los existentes de sus puestos y evitar que nuevos psicópatas accedan a cualquier puesto de responsabilidad.

Las medidas a tomar serían mucho más baratas que la alternativa, y probablemente no son nada complejas de implementar tanto a nivel público como privado (tests, biométrica, EEG, anális de oxitocina...). Las entrevistas, las oposiciones y los mecanismos de promoción interna podrían implementar test para identificar a personas sin empatía ni conciencia y eso seguramente nos llevaría a conseguir empresas y sociedades sin Lehman Brothers, Emilios Botín, Esperanzas Aguirre* o Leires Pajín*. Es decir, que con un par de medidas sencillas (identificar y apartar) tendríamos una sociedad más justa, productiva y limpia. Y la tendríamos de golpe, sin tener que esperar décadas.

Además a día de hoy, con las notannuevas tecnologías, podríamos tener datos estadísticos de toda una vida para poder identificar de manera más fina a los futuros psicópatas o a las organizaciones que hacen psicópatas. Imaginemos que analizando datos históricos de los últimos 5 años, vemos que grupos de personas que son "normales" empiezan a hacerlo mal en sus test de empatía cuando empiezan a trabajar en una empresa en particular. Eso indicaría que la empresa debería ser inspeccionada, sancionada o marcada de alguna manera para que la gente pudiera evitarla. Y nos ahorraría unos cuantos psicópatas funcionales más en el mundo. Ah y como efecto colateral de reducir el impacto de los psicópatas quizá podríamos reducir crímenes de género, suicidios, depresiones y acosos laborales.

Por supuesto todo esto es ciencia ficción sin una legislación que le de forma y algunos organismos estatales de apoyo (Sanidad, Trabajo, Hacienda). Y dado que los legisladores (partídos políticos mayoritarios) parecen tener completamente comprometidas sus jerarquías con corruptos y psicópatas, mucho me temo que solo nos queda rezar para que alguna empresa privada no contaminada consiga una posición tipo Google/Microsoft que le permita instaurar estas medidas al margen de todo (como prueba de que funciona) y montar un lobby de presión al respecto.


*Nota: Si crees que Aguirre o Pajín no tienen signos de psicopatía o no deberían ser puestas a prueba, considera seriamente la posibilidad de estar bajo los efectos de un lavado de cerebro.

Imagen del post obtenida de la Wikimedia.

sábado, enero 14, 2012

Libro: Rework



Titulo
: Rework
Autor: Jason Fried y David Heinemeier Hansson
Editorial: 37Signals (supongo)

Hace un par de semanas terminé de leer uno de los libros de la gente de 37signals, Rework, que habla de su filosofía y experiencias en el desarrollo de software, la gestión de personas, el trato a los clientes, y en definitiva, todas las áreas no puramente técnicas sobre el negocio del software.

Se trata de un libro muy fácil de leer, con el que es difícil estar en desacuerdo (si no lo estás, me interesaría saber por qué, y si alguna vez has desarrollado un producto) y que a pesar de no ser exhaustivo, es una muy buena recopilación de consejos prácticos si quieres vivir con el software.

El estilo del libro recuerda al del Guy Kawasaki y es de los que van directo al grano, sin historietas ni adornos. Pura experiencia para el que la quiera o pueda aprovechar.

Como se trata de un libro muy variado, que está parcialmente online, e incluso traducido (aunque no parece muy buena traducción por lo poco que he visto de ella), y como ya hay medio millón de reviews en Internet, me abstendré de recopilar citas interesantes y me centraré en una que desgraciadamente sufro en mi puesto actual: considerar todo como urgente (ASAP:as soon as possible).
ASAP is poison Stop saying ASAP.
We get it. It's implied. Everyone wants things done as soon as they can be done. When you turn into one of these people who adds ASAP to the end of every request, you're saying everything is high priority. And when everything is high priority, nothing is. (Funny how everything is a top priority until you actually have to prioritize things.) ASAP is inflationary. It devalues any request that doesn't say ASAP. Before you know it, the only way to get anything done is by putting the ASAP sticker on it. Most things just don't warrant that kind of hysteria. If a task doesn't get done this very instant, nobody is going to die. Nobody's going to lose their job. It won't cost the company a ton of money. What it will do is create artificial stress, which leads to burnout and worse. So reserve your use of emergency language for true emergencies. The kind where there are direct, measurable consequences to inaction. For everything else, chill out.
Para terminar, solo comentar que es un libro indispensable si quieres hacer un buen trabajo con el mínimo de recursos, si trabajas en una PYME, en una startup, si planeas montar un producto o si te interesa conocer otras maneras de funcionar a parte de las que venden las megaconsultoras.

domingo, enero 08, 2012

Funda Kensington para iPad 2



La verdad es que Kensington hace unas fundas estupendas. Esta en particular protege el aparato (el iPad 2 de la entrada anterior) completamente (pantalla, bordes y parte trasera) mediante estructuras rígidas y elegantes que no desmerecen en absoluto el diseño del aparato que protege. Pero lo hace dejando accesibles los botones, altavoz y conectores.

Es cierto que añade algo de peso extra, pero mejora el agarre del aparato y protegen el metal y plástico de arañazos, golpes y el sudor de las manos. Porque el sudor es algo que se tiende a olvidar pero he visto como este puede comerse el recubrimiento de metal de algunos objetos, así que ojo con usar solamente una tapa para este trasto que va a estar en nuestras manos durante periodos prolongados.

La tapa, aun siendo rígida, tiene un doblez que permite convertirla en soporte vertical u horizontal de modo que sea cómodo para ver vídeos y escribir en el teclado. Pero además tiene un imán que activa el apagado y encendido automático de la pantalla (configurable por software en el propio iOS) por lo que ya no necesitamos botones para usarlo en ruta y se asemeja más a un libro en cuanto a uso.









Por último solo comentar que me parece bastante barata en comparación con lo que hay por ahí, y la gente de Amazon España te la lleva a casa en un periquete.


afafLa verdad es que Kensington hace unas fundas estupendas. Esta en particular protege el aparato completamente (pantalla, bordes y parte trasera) mediante estructuras rígidas y elegantes que no desmerecen en absoluto el diseño del aparato que protegen. Pero lo hace dejando accesibles los botones, altavoz y conectores. 

Es cierto que añade algo de peso extra, pero mejora el agarre del aparato y protegen el metal y plastico de arañazos, golpes y el sudor de las manos. Porque el sudor es algo que se tiende a olvidar pero he visto como este puede comerse el recubrimiento de metal de algunos objetos, así que ojo con usar solamente una tapa para este trasto que va a estar en nuestras manos durante periodos prolongados. 

La tapa, aun siendo rígida, tiene un doblez que permite convertirla soporte vertical u horizontal de modo que sea cómodo para ver vídeos y escribir en el teclado. Pero además tiene un imán que activa el apagado y encendido automático de la pantalla por lo que ya no necesitamos botones para usarlo en ruta y se emeja más a un libro en cuanto a uso. 

Por último solo comentar que me parece bastante barata en comparación con lo que hay por ahí, y la gente de Amazon España te la lleva a casa en un periquete. 

Por último solo me queda recomendar las fundas de Kensington de este tipo para cualquier tablet. De hecho, hay una para el Samsung Galaxy Tab aun mejor que esta. 
 verdad es que Kensington hace unas fundas estupendas. Esta en particular protege el aparato completamente (pantalla, bordes y parte trasera) mediante estructuras rígidas y elegantes que no desmerecen en absoluto el diseño del aparato que protegen. Pero lo hace dejando accesibles los botones, altavoz y conectores. 

Es cierto que añade algo de peso extra, pero mejora el agarre del aparato y protegen el metal y plastico de arañazos, golpes y el sudor de las manos. Porque el sudor es algo que se tiende a olvidar pero he visto como este puede comerse el recubrimiento de metal de algunos objetos, así que ojo con usar solamente una tapa para este trasto que va a estar en nuestras manos durante periodos prolongados. 

La tapa, aun siendo rígida, tiene un doblez que permite convertirla soporte vertical u horizontal de modo que sea cómodo para ver vídeos y escribir en el teclado. Pero además tiene un imán que activa el apagado y encendido automático de la pantalla por lo que ya no necesitamos botones para usarlo en ruta y se emeja más a un libro en cuanto a uso. 

Por último solo comentar que me parece bastante barata en comparación con lo que hay por ahí, y la gente de Amazon España te la lleva a casa en un periquete. 

Por último solo me queda recomendar las fundas de Kensington de este tipo para cualquier tablet. De hecho, hay una para el Samsung Galaxy Tab aun mejor que esta.