La titulitis ha muerto

dilbert-university-mbaDe nuevo, seguimos viendo titulares que insisten en que las grandes multinacionales (en este caso es Google quien se suma al carro de otras como Microsoft, etc.), ya no miran el expediente académico.

¿Para qué sirve pues estudiar? Pues se está perdiendo la noción enquistada y del siglo pasado de que estudiar sirve como garantía para encontrar un buen empleo, para garantizar el éxito en la vida. Al final va a resultar que estudiar, sirve simplemente, para adquirir conocimientos, y no es una garantía exclusiva y universal de un empleo de alta remuneración.

Ya hace tiempo que se habla de ello, y es que la universidad prepara universitarios. Pero las empresas necesitan profesionales.

¿Qué ocurre ahora, al salir de la universidad? Pues que hay que ganarse el pan. Ya no sirve hacer un esfuerzo puntual durante un tiempo para sacarse el título. Ahora cada día es una prueba de aptitud, y se nos pone a prueba en nuevas y cada vez más complejas situaciones: se llama realidad competitiva profesional.

Después de todo, ya hemos hablado en artículos anteriores de los job-hoppers (*), que saltan de empleo en empleo para mejorar su situación laboral. Al contrario, las empresas también nos exigen cada día más un pequeño (y a veces no tan pequeño) esfuerzo de superación, de mejora. Pequeñas batallas que pueden terminar si o si de dos formas:

  • Triunfando, y por tanto, aprendiendo de las buenas prácticas y criterios aplicados.
  • Fallando, pero aprendiendo de qué se aplicó de forma incorrecta, o qué premisas eran inadecuadas para la situación.

Este tipo de corrientes de pensamiento supongo que molestarán a los que llegaron con su carrera universitaria y su MBA pensando que ya no tendrían que esforzarse. Que para ganar dinero basta SER y no HACER. Se les olvida recordar que el cliente paga por lo que recibe de nosotros, no por lo que somos.

Fuente:http://www.elmostrador.cl/noticias/mundo/2016/01/24/google-cambia-su-forma-de-contratar-personal-el-expediente-academico-no-sirve-para-nada/

(*) Como ya me comentaba una lectora en una entrada anterior, el término job-hopper no debe usarse para los que ven forzado su cambio de trabajo de forma constante, sino para los que lo buscan y fuerzan como una medida de garantizar una promoción laboral continua y sostenible.

Anuncios

Sobre iniciativas y proactividad

Dilbert-iniciativa.pngHoy hablaremos sobre las iniciativas y la proactividad. ¿A qué nos referimos con iniciativa? Pues una iniciativa se define como “proposición o idea para iniciar alguna cosa”. Hay otros significados, pero hoy hablaré de este. Es el primer paso de un proyecto, o el punto de partida de alguna acción.

¿Qué problema hay con las iniciativas? Que son muy bonitas, son útiles, pero promover iniciativas es una trampa. Y es una trampa, porque pensemos en el caso de que la persona que propone las iniciativas es la misma persona que debe ejecutarlas y llevarlas a cabo. Pues en ese caso las iniciativas son como pegarse un tiro en el pie: cuantas más ideas propone esa persona, y/o mayores son, más trabajo debe asumir.

Y al contrario, es muy bonito soltar ideas e iniciativas, cuando han de ser otros los que las terminen y lleven a buen término. Después de todo, alguien  lo llevará a cabo. No importa lo ambicioso o complejo de la iniciativa, o incluso no importa si las iniciativas son plausibles o no.

¿Y qué ocurre con la proactividad? Veamos. La proactividad se define como “toma de iniciativa en el desarrollo de acciones creativas y audaces para generar mejoras”. Muy bien, vemos que la proactividad es una medida de las iniciativas que llevamos a cabo.  Por desgracia, la proactividad, se verá bloqueada por el razonamiento anterior de las iniciativas:

Es fácil ser proactivo cuando otros han de llevar a cabo las iniciativas, o cuando éstas son sencillas. Es fácil tener iniciativa. Lo complejo es poder asumir su ejecución.

En un entorno empresarial, se suele premiar la iniciativa o más concretamente, la proactividad de las personas. Sin embargo, no es un buen indicador, ya que las personas que prevean que van a tener que asumir la ejecución de las iniciativas, se van a ver animadas precisamente a no presentar iniciativas.

Por tanto, podemos obtener este interesante corolario:

El tamaño y complejidad de una iniciativa, suele ser inversamente proporcional a nuestra implicación en la realización directa de las mismas.

Claro, a no ser que compenses la desmesurada magnitud de tus iniciativas, con pasión y amor por tu trabajo. Así que si eres de los que pecan de lo primero, asegúrate antes de ir sobrado de lo segundo.

Un muy buen fin de semana a todos.

 

La línea de Base y los cambios en producción

branch-per-taskMuchos me diréis que a qué viene esto ahora a cuento. Pues me sigo encontrando muchos casos en los que hay programadores que no terminan de entender el concepto de línea base. Además, este concepto es fundamental para entender los cambios en el ciclo de vida del software, desde el entorno de desarrollo, hasta el de producción. Y no, no me refiero a permitir o no hacer cambios directamente en producción. De eso creo que ya hemos hablado. Me refiero a controlar los cambios en cualquier entorno mediante el concepto de línea base.

¿Qué es la línea base?

La línea base es un concepto de la gestión de la configuración (otro día hablaremos de ella). La línea base se define en el IEEE 600.12/1990 como:

Una especificación o producto que se ha revisado formalmente y sobre los que se ha llegado a un acuerdo, y que de ahí en adelante sirve como base para un desarrollo posterior y que puede cambiarse solamente a través de procedimientos formales de control de cambios.

La línea base es un contrato. Un contrato igual que lo es una API, o el WSDL de un servicio web. La línea base establece en qué puedo confiar, porque es algo acordado (ni siquiera tiene porqué ser bueno, probado, excelente o definitivo). Hablamos de una versión de cada uno de los componentes software, que en conjunto, se ha acordado que es correcta en su conjunto. Pero sin suponer esto que cumpla los requisitos, ni las pruebas…simplemente es un hito.

Cuando trabajas con Subversión, TFS o Github, tenemos los conjuntos de cambios, tags o Changesets. Esas etiquetas o paquetes de cambios identifican el software en su conjunto, y son como una foto. Sí, como una foto del software en un momento y situación determinados del tiempo.

Aquí la idea no es versionar. No es un control de cambios. Es tener la posibilidad de devolver todo el código a un momento del tiempo en el que sabíamos que algo funcionaba (o no), pero al menos conocíamos su estado en conjunto. Esto es muy importante para controlar el estado de los entornos, para poder devolver un entorno (pruebas, desarrollo, calidad, preproducción, formación, producción), a un estado conocido.

Si la línea base es una foto, instalar una línea base es devolver a un entorno a un estado conocido, es un viaje al pasado.

Por ese motivo, jamás deberemos tocar el código en producción, ni en pre-producción, ni en otro entorno que no tengamos debidamente controlado con el correspondiente gestor (SVN, Github, TFS…). Porque si tocamos el código, hemos perdido la partida. Ya no podremos tener control de hacer una nueva “foto”, y empezaremos a perder el control de los cambios, de los entornos, del desarrollo.

Y claro que podemos coger ese código, hacer un checkout en desarrollo y poner ese código después para recuperar el estado del entorno de desarrollo. Y claro, también existe Santa Claus, y Blancanieves, y los siete enanitos. Si no lo hicimos en un principio, si nos hemos dejado seducir para tocar el código en producción y “jugárnosla”, hemos perdido el control y ha dejado de jugar a nuestro favor todos los beneficios de la integración continua, testing automático, etc, etc.

Alguna vez he oído decir que tocar el código en producción es como dejarse seducir por el lado oscuro de la fuerza. Tentador…pero no sólo es algo que esté mal…es algo cuyo precio vas a pagar tarde o temprano.

Habilidades vs títulos (episodio 2)

dilbert-certification

Si hace poco hablába de la titulitis en el artículo “Habilidades vs títulos” (que ahora deberé renombrar añadiéndole “episodio 1”), ahora va el jefe de Recursos Humanos de Google y suelta la frase: “el expediente académico no sirve para nada“.

Y es que nos pongamos a la defensiva o no, se está demostrando cada día más que la postura de “yo valgo porque mi título es tal o cual”, ha muerto, y debería considerarse una postura conformista y obsoleta.

Por desgracia, todo cambia, y debemos adaptarnos. Ya nunca más el tener un título va a suponer una ventaja absoluta, y debemos mirar con otros ojos (y con el debido respeto profesional), a los que han elegido otras vías de formación. Debemos valorar por capacidades, no por títulos.

Tal y como afirma el jefe de RRHH de Google, lo que se enseña en la universidad es muy distinto de lo que se necesita en el mundo laboral. La paradoja, tal y como desarrolla en el artículo, es que la universidad enseña…a superar la universidad. Del mismo modo que el hacer muchos Test Psicológicos entrena a superarlos (no necesariamente desarrolla el intelecto, aunque aparentemente los resultados de tus test sean exponencialmente mejores). De ahí se deduce que una persona que saca muy buena puntuación en un test…sólo significa eso y nada más. Para resolver problemas reales…hay que enfrentarse a problemas reales.

En el artículo, es curioso como una de las preguntas favoritas del jefe de RRHH de Google es “Dame un ejemplo de cómo resolviste un problema analítico difícil”. Aquí empieza a verse la luz valorando la experiencia, al mismo tiempo que una mente inteligente.

 

ÑaaS (Ñapa as a Service)

ñapa-as-a-serviceHoy os traigo una delicatesen que un buen amigo me ha proporcionado. Como ilustra la figura adjunta, la ñapa es una de las lacras de esta profesión del desarrollo de software, y por desgracia, hay quien la ofrecen como servicio de forma habitual.

Quiero pensar que el autor de la imagen, al escribir “Programming the spanish way”, no hablaba en serio. Me niego a pensar que la forma habitual de programar en España sea la Ñapa.

Para los lectores de otros países, o que me lean mediante el traductor automático, vamos a ofrecer una traducción del término “Ñapa”. No os molestéis en buscar en la RAE (Real Academia Española de la lengua). El término Ñapa no aparece allí. Sin embargo, es harto conocido al menos en España

ÑAPA: chapuza, mierda, parche, remiendo. En informática, dícese del trabajo mal remunerado y peor ejecutado, que consiste en construir un simulacro de aquello que espera ver el cliente, con el mínimo esfuerzo, y totalmente alejado de lo que una mente sana entendería como adecuado.

Eso es una ñapa. Este término está muy relacionado con otros que ya he blogueado (y algunos que aún no he terminado de escribir) como: cantamañanas, o vendemotos, o vendedor de humos (smokeseller para los amigos). Es gracias a esta fauna de la selva informática, a quienes debemos agradecer la existencia de las ñapas.

También hay que agradecerlos a los clientes, que también los hay, que son capaces de cambiar de opinión cada poco tiempo para disfrute de los programadores. Esos programadores que se encuentran que después de docenas o cientos de horas construyendo aplicaciones, éstas dejan de tener sentido debido a “un pequeño cambio”.

Y me rio, me parto de la risa ácida que me entra de forma visceral e insostenible, cuando me salta el iluso de turno con su “esto se arregla siendo ágil”. Amigo, esto no lo arregla SCRUM, ni CMMI ni nadie. Cuando el cliente decide que lo más importante no es identificar el impacto de un cambio, ni priorizarlo. Solamente llevarlo a cabo. Aunque haya que tirar a la basura semanas y semanas de duro trabajo para rehacer desde cero miles de líneas de código.

La ñapa o chapuza, es una enfermedad del software (podéis leer más enfermedades del software que he ido recopilando en esta categoría, como la comentitis, singletonitis, excusitis, cacheitis, patronitis… ). Y esta enfermedad es difícil de erradicar. Desde mi experiencia, lo más importante no es la metodología, no es ser más o menos ágil. Sino ser consecuentes y tener la mente fría. Identificar el impacto de las cosas, y asumir que los cambios existen, y que la forma más rápida de llevarlos a cabo es precisamente…no ponerse a ellos de forma inmediata. Sino ponerlos en cartera y ver cómo se relaciona con otros cambios solicitados, los desarrollos en curso, etc, etc.

Gracias José Antonio Herrero por la imagen.

El fin de los mensajes de error

error-messageLeía en linkedin un artículo de opinión (Error Messages are Evil), y mi sorpresa ha sido mayúscula al encontrar que se había formado todo un terremoto de respuestas, una pequeña polémica. Y mi sorpresa ha sido aún mayor al encontrar a gente joven entre los que responden en contra de la opinión del autor. En el artículo, el autor (Don Norman), defendía que los mensajes de error son el mal, y mostraba como ejemplo un mensaje de error ofrecido por una aplicación.

Yo esperaba que los usuarios más jóvenes apoyaran por fin estos conceptos de usabilidad, pero parece que al menos entre los lectores del artículo, no era así.

Y sí, estoy de acuerdo, los mensajes de error son malignos. Realmente, hay que erradicarlos. Ya lo comentaba hace tiempo Alan Cooper, uno de los maestros del UX en “The inmates are running the asylum”. Los mensajes de error tradicionales violan las reglas de la usabilidad:

  • Hacen sentir estúpido al usuario, al culparle por no saber usar el software.
  • Distraen del objetivo del usuario, que no es usar el software, sino obtener resultados.

¿Por qué decimos al usuario lo que hay que hacer DESPUÉS de que lo haga? ¿Porqué asumimos que es un error algo como un texto mal introducido? ¿Porqué no nos centramos en guiar al usuario a cumplir sus tareas en lugar de obsesionarnos en que use “correctamente” nuestro software?

Pues porque al desarrollar software, caemos en la trampa del egoísmo. Sólo pensamos en nosotros mismos, de forma que cuando el usuario no hace lo que nosotros queremos/esperamos…es SU culpa! Malditos usuarios…

Bueno, no puedo irme sin recomendaros no sólo el artículo de opinión en sí, sino esa gran obra  pionera en el mundo del UX (User Experience) que es “The inmates are running the asylum”.

Enfermedades del software: Singletonitis

Patrón Singleton en notación UML

De nuevo, una enfermedad del software que a más de uno le va a sorprender. Y sin embargo es muy pero que muy vieja. Al final de esta entrada tenéis unos cuantos ejemplos de fuentes que he utilizado y que me han recordado lo peligroso que es usar patrones sin conocimiento, pero especialmente, el más simple de todos: el patrón Singleton.

¿En qué consiste el patrón Singleton?

Este patrón es el más sencillo, y también uno de los más conocidos y utilizados. Básicamente, su propósito es asegurar que sólo exista una instancia de una clase dada.

Singletonitis, una definición

Bien, dada la definición anterior, el anti-patrón Singleton ha recibido el nombre de “singletonitis”: desorden transitorio del programador, que le lleva al abuso del patrón Singleton. Algunos autores van más allá, y definen claramente al patrón Singleton como un verdadero anti-patrón (es más causa de problemas, que solución de ninguno: o como se suele decir, pan para hoy, y hambre para mañana).

En el libro “Refactoring to Patterns”, el autor Joshua Kerievsky presenta el término Singletonitis, refiriéndose literalmente a “la adicción al patrón Singleton”. Este autor, propone un tipo de refactorización que llama “Inline Singleton”, cuyo objetivo es eliminar los Singletons innecesarios en una aplicación.

Hay muchos problemas con el patrón singleton. Demasiados. Algunos de ellos:

  • Crea una alta dependencia en el código. Un alto acoplamiento que es fuente de problemas
  • Crea problemas con las pruebas y su automatización, especialmente por la alta dependencia del código al tratar de hacer pruebas unitarias.
  • Problemas con el multi-hilo y concurrencia.
  • Alta probabilidad de crear spaguetti-code, difícil de leer e incluso de debuguear, por acumulación de uno o varios de los anteriores.
  • Problemas de reusabilidad. Lo mismo, por acumulación de uno o varios de los anteriores.

En uno de los artículos que he revisado, el autor (Taskinoor Hasan ), ha tratado de hacer una aproximación seria, tratando de dar una solución lógica a los diversos problemas que el autor va detectando en su inocente implementación del patrón Singleton. De tan serio que es el artículo, y la acumulación sucesiva de problemas que presenta, acaba siendo hasta ridículo y divertido.

Del tema de la concurrencia y problemática con los entornos multi-hilo, hay varios artículos que presentan estrategias más o menos eficaces en función de la situación, lo que complica la resolución del problema. Y es que hay que ver lo bonito que es todo cuando en nuestra ignorancia, planteamos un sistema con Singletons creyendo que éstos van a ser instancias mono-uso. Con el paso del tiempo, la experiencia (y la dura realidad), nos van enseñando que al ver las cosas desde un nivel superior, o al tratar de reutilizar componentes, nuestro pequeño patrón Singleton es una fuente de problemas. Además, esos problemas al haber tanto acoplamiento en el código y dificultad de testeo, son complicados de detectar y resolver.

Frases como “esto nunca se va a usar en multi-hilo”, tan categóricas, deberían ir siempre acompañadas de un “zas, en toda la boca”.

Es duro ver cómo la falta de previsión y el abuso de patrones (patronitis), hace que las cosas se usen fuera de contexto y acaben haciendo todo menos aquello para lo que fueron diseñadas.

Solución: ¿vacuna o erradicación?

No son pocos los autores que defienden la total prevención mediante la erradicación de la causa de la Singletonitis, evitando dicho patrón.
Otros, elaboran complejísimas estrategias para detectar problemas, incompatibilidades, etc. Incluso existe una estrategia de validación dentro del patrón llamada “Double Check Locking“, diseñada para evitar que en el caso de multi-hilo, haya problemas derivados de los bloqueos necesarios dentro del patrón.
Yo propongo algo que varios de los autores defienden, y es el uso de otro patrón (que por supuesto tendrá su enfermedad asociada por abuso), y es el de IoC (Inversion of Control).

¿Y tú? ¿Ya has sufrido tu Singletonitis?…

Fuentes:

http://taskinoor.wordpress.com/2011/04/18/singleton_multithreaded/
http://www.antonioshome.net/blog/2006/20060906-1.php
http://pragmaticintegration.blogspot.com.es/2006/02/singletonitis.html
http://www.theserverside.com/discussions/thread.tss?thread_id=42116
http://www.gamedev.net/blog/32/entry-510687-why-are-you-infected-with-singletonitis/
http://msdn.microsoft.com/es-es/library/bb972272.aspx
http://www.teatromagico.net/foro/viewtopic.php?f=4&t=13513&p=454983
Gamma E., Helm, R., Johnson, R., Vlissides J.: Design Patterns: Elements of Reusable Object Oriented Software, Addison Wesley, 1995.
Kerievsky, Joshua: Refactoring to Patterns, Addison-Wesley, 2004.
http://weblogs.asp.net/sfeldman/archive/2008/10/22/singletonitis.aspx