Reseña libro Clean Code

Hoy os traigo una revisión de un libro sobre programación. No tanto sobre un lenguaje sino sobre la programación en general, buenas prácticas. El libro se llama Clean Code.

Creo que es un libro que todo programador debiera de leer.

Os dejo el vídeo

Espero que os guste

Como acelerar el arranque de una persona en un nuevo proyecto

En esta ocasión quería comentar una herramienta para configurar y distribuir servidores. Concretamente la herramienta se llama Docker

Para ver qué es lo que nos puede aportar Docker vamos a plantear una problemática muy común en las empresas de desarrollo.

Llega una nueva persona al equipo del proyecto y… ¿ cual es una de las primeras cosas que suele tener que hacer ?,… efectivamente, ponerse el entorno.

En muchos sitios este trámite consiste en que algún compañero le haga un zip de su servidor y de su herramienta de desarrollo y se lo pase.

El compañerismo está muy bien, pero esta forma de proceder no es la más adecuada, porque se acaba arrastrando mucha porquería, ya que no es un entorno limpio.

Sin contar que tampoco suele haber ningún mecanismo para tener actualizado el entorno. Así que cuando se libera una nueva versión de alguna librería o del servidor toca actualizarse manualmente.

Y aquí entramos en:

– personas que no lo hacen porque tienen que entregar algo sin falta y van apurados.
– o personas que al seguir el manual de como actualizar se equivocan.
– o simplemente personas que tiene montado el entorno a su manera.

Total que con esta forma de proceder el tener un entorno actualizado es casi una quimera o de conseguirse el coste es muy alto. Y estas operaciones se repiten bastante a menudo dentro de un proyecto un poco grande y largo.

Pero hay soluciones, una de las que más auge está tomando últimamente es Docker.

Tengo un ejemplo muy simple, en youtube, que consiste en un servidor WildFly, que es la versión de la comunidad del JBoss, con un módulo instalado para obtener métricas de la ejecución de nuestra aplicación, que viene a simular las librerías específicas de un proyecto y una aplicación muy sencilla de ejemplo.

Las herramientas que se usan en este vídeo son las siguientes:
– Docker versión 1.9
– Docker Hub
– JBoss Developer Studio 9.0.0
– WildFly 9.0.2
– Dropwizard metrics

Espero que os sirva de ayuda, y no dudes en dar a like y compartirlo.

Innovación

A los profesionales con inquietudes nos suele gustar innovar en nuestro trabajo, pero cuando trabajas para terceros no siempre es fácil. Debemos tener muy presente que toda mejora supone un cambio, pero no todo cambio supone una mejora. Lo importante de la innovación es aportar valor al cliente. 

Cuando te encuentras trabajando para una organización que ya tiene establecidas sus herramientas y metodologías es complicado poder innovar, porque si quieres hacerlo sobre algún área ya definida por la organización vas a tener que proponer algo que realmente les aporte una sustancial mejora, ya que sino acabamos cambiando y no mejorando. Y no es fácil salvo que te encuentres trabajando para una organización con planteamientos y herramientas obsoletas.

Para matar el gusanillo suele ser más útil el buscar algún reducto donde la organización no se haya desarrollado. De esta forma con no mucho trabajo puedes conseguir proporcionar mucho valor al cliente. Es una tarea no precisamente fácil, sobre todo cuanto más organizada y moderna sea la organización, ya que tendrá cubiertos las principales áreas. 

Curriculum vs. pasión

Últimamente está muy de moda dentro del agilismo y todas estas prácticas de emprendimiento el recalcar la importancia del la pasión en el trabajo y que el currículum hoy día tiene poca validez, ya que es una herramienta 1.0 del siglo pasado.

A veces hay conceptos que cuesta un poco asimilar y aunque puedes entender que efectivamente es importante la pasión en el trabajo, no es tan fácil entender porque un currículum no es algo tan válido hoy día. Pero últimamente se han dado una serie de circunstancias que me han hecho entender cual es esa diferencia.

Yo, por ejemplo, (y no tiene nada que ver con esas circunstancias que he comentado) en mi currículum puedo poner que he dado formación y es cierto, y no lo hacía mal del todo. Pero es algo que siempre he intentado evitar, porque no me gusta. Es lo que tiene el curriculum que o mientes quitando cosas o si realmente lo que estás diciendo es la realidad, es como su nombre indica, el discurrir de la vida y yo efectivamente… he sido profesor.

Pero por ejemplo sí vemos el blog, este blog que estás leyendo, podrás darte cuenta de que cosas son las que me interesan, porque nadie me obliga a escribir lo que escribo, simplemente escribo lo que me apasiona o lo que me molesta.

Para mi esa es la validez que tiene este blog, es una forma de expresar claramente qué cosas son las que me apasionan y que cosas no. No quiere decir que todo de lo que no escriba aquí lo aborrezca hay cosas que simplemente no tengo tiempo para abordarlas y otras que si que efectivamente pues ni si ni no, las he hecho porque tocaba hacerlas.

Nuestro rol como clientes y proveedores y sus paradojas

En la vida de cada uno de nosotros en la mayor parte de las situaciones somos consumidores de productos o servicios. Compramos cosas, como ropa, electrónica, etc, o bien contratamos servicios, como por ejemplo la línea telefónica.

Y normalmente somos exigentes con las compañías que nos prestan estos servicios. Es lo normal, pagamos por un producto y servicio y queremos que nos lo presten correctamente. A nadie le gusta quedarse sin cobertura en el teléfono, o que no le funcione el terminal, o que el medico no le diagnostique bien, o un largo etcetera.

A veces lo que nos ocurre como trabajadores es que no nos damos cuenta que en ese momento nosotros somos los prestadores del servicio. Y lógicamente nuestros clientes van a tener un nivel de exigencia similar al que nosotros tendríamos si fuésemos los clientes. Y se nos suele olvidar.

¿Que pensaríamos si estamos reformando la cocina de nuestra casa y el albañil cuando llega la fecha de entrega nos dice que va a tardar más? Lógicamente lo más probable es que no nos parezca bien, no vamos a disponer de nuestra cocina, con el trastorno que nos supone, y encima nos va a costar más, porque obviamente el albañil no va trabajar gratis.

Pero me he encontrado con casos en este sector de la informática en los que gente del equipo se permite plantear que se le pida más tiempo al cliente. Y lo más curioso es que luego cuando las cosas van mal y el cliente te echa se extrañan.

Pero ¿alguien mantendría o volvería a contratar al albañil que obviamente está siendo incapaz de llevar la reforma de la cocina a cabo?.

¿Está tu equipo preparado para autogestionarse?

En scrum se propugnan los equipos autogestionados. Pero la pregunta es ¿Está tu equipo preparado para autogestionarse?

Aunque suene muy interesante la autogestión de un equipo hay ciertas dificultades para llevarlo a cabo. Normalmente los equipos, y consiguientemente los integrantes del equipo, están acostumbrados a tener un jefe que les indique lo que tienen que realizar.

Prescindir de esa figura que se encarga de gestionar el equipo puede ser traumático, por varios motivos.

Cuando los integrantes del equipo están acostumbrados a que alguien se encargue de la gestión, normalmente no se preocupan de como se gestiona, que cosas hay que tener en cuenta, que criterios hay que seguir para priorizar tareas, o para asignarlas, etc.

Así que se corre el riesgo de que cuando el equipo se autogestiona cometa muchos errores por inexperiencia.

Hay que tener en cuenta que aunque el equipo se autogestione eso no implica que todo el mundo se vuelva un experto en todas las materias. Hay que conocer los límites de cada uno y no decir o proponer cosas que luego se comprueben que no son adecuadas, ya que es contraproducente a nivel personal. Si en el equipo, por ejemplo, hay un experto en la funcionalidad del aplicativo, cuando se traten temas de funcionalidad hay que tener muy en cuenta su opinión.

La autogestión no significa tampoco la anarquía o el barra libre. Los acuerdos a los que se llegue dentro del equipo hay que respetarlos, independientemente de que nos parezcan adecuados o no. Los informáticos desgraciadamente somos muy dados a ir por libre, pero es completamente contraproducente, sobre todo porque si el equipo demuestra que no es capaz de autogestionarse, tarde o temprano les acabarán volviendo a poner a un gestor.

No sería el primer equipo que veo autogestionarse hacia el fracaso.

Reflexiones del BilboStack

Hace ya una semana que se celebró el BilboStack. Un acto realmente interesante, con algunas intervenciones incluso con gente en los pasillos.

Hubo una intervención que me gustó especialmente, y eso que fue un substituto de última hora. Fue sobre la deuda técnica que expuso Rodrigo Corral. No es que las otras intervenciones estuviesen mal, todo lo contrario, es que esta fue la que más me hizo reflexionar.

Nuestra profesión tiene un componente muy importante de sector servicios, es decir tenemos clientes que nos piden cosas y nosotros se las hacemos. No muy diferente de lo que puede ser, por ejemplo un pintor, al que si un cliente le pide que le pinte la casa de naranja, independientemente de sus gustos se la tiene que pintar de naranja.

El BDD y AngularJS están muy bien, pero al final, lo primordial es hacer un trabajo de calidad y para ello hay que involucrar también a los clientes. Si para tener poca deuda técnica hay que invertir un poco más al principio, salvo que el cliente lo entienda y asuma, no vas a tener muchas posibilidades de “tardar más” y hacerlo mejor.

En esta línea me pareció muy oportuna la pregunta que le hizo un antiguo compañero de trabajo, sobre como evangelizar sobre la deuda técnica.

Estoy leyendo un libro de Clean Code que recomendaron y una de las cosas que dice el autor y con razón es que a nadie se le ocurre decirle al cirujano antes de una operación que no hace falta lavarse para desinfectarse y que se meta al tema rápidamente, y eso que el paciente es el que paga la operación. Aparte de que el cirujano se negaría en redondo a hacerlo. Pero en este sector los técnicos no tenemos ese grado de autoridad.

Quizá a estas reuniones tendrían que asistir los clientes más que los técnicos.

Inquietudes en el desarrollo de software

Hace unos días Javier Garzás publicó una entrada en su blog sobre el probable futuro del desarrollo de software, que me parece muy interesante de leer. Y me parece muy interesante porque viene de alguien que tiene contactos con diferentes sitios, con lo que te da una visión más amplia que cuando estás enfrascado en tu negocio o cliente, con sus particularidades propias.

Yo añadiría otro futuro, que me inquieta, porque lo he vivido en el pasado. Me explico. Cuando yo empecé en el mundo del desarrollo lo que se llevaba era el hacer webs más bien publicitarios y comercios electrónicos.

Hoy día muy pocas empresas, por no decir casi ninguna se plantea el realizar su portal o su comercio electrónico totalmente a medida, básicamente porque hay multitud de paquetes para hacerlo. Tanto paquetes para construir portales o comercios electrónicos pequeños, como grandes.

Hoy día se ha pasado en estas áreas de desarrollar a parametrizar un paquete, con algún desarrollo para hacer alguna adaptación. Pero y ano existe el empezar, como dirían los escritores, con una hoja en blanco.

Para una persona que se dedica al desarrollo de software a medida, el paquetizado es una amenaza. Sobre todo porque el software a medida es muy caro y muchas veces de una calidad baja.

¿Donde está el Gordon Ramsay de la informática?

Esta semana pasada he andado algo acatarrado/griposo así que he pasado bastante tiempo en la cama echo un trapo y haciendo zapping he visto algunos capítulos de pesadilla en la cocina en su versión americana.

Lo más curioso del asunto es que ves situaciones en un negocio de restauración que también he visto en sitios por los que he pasado como informático. Falta de liderazgo, por unos u otros motivos, gente que funciona por amiguismos, personal desmotivado, falta de calidad, etc.

Sobre el tema del amiguismo no me puedo quitar de la cabeza una dueña que había cogido el restaurante en el que trabajaba de camarera y no había cambiado nada así que defendía a su amigo al chef… que no sabia hacer ni una albóndiga.

Puede parecer un poco extraño, pero al final muchos de los problemas en una empresa son problemas con las relaciones entre las personas y el trabajo, no simplemente con el trabajo.

Teletrabajo

Estaba leyendo un artículo de un americano que habla sobre la experiencia de trabajar sin ir a la oficina, es decir el teletrabajo.

Mi primer trabajo fue para montar un telecentro y algo me informé del tema. Hay que decir que eso fue sobre el 98, así que las comunicaciones no estaban tan desarrolladas como ahora.

Es muy tentador el no ir a trabajar, o más bien no ir al trabajo. Me acuerdo que en algunos estudios recomendaban que aunque no fueses a la oficina te comportases como si lo hicieses. Es decir marcándote unas rutinas, incluso vistiéndote para el trabajo (nada de currar en pijama) y teniendo una habitación para el trabajo. Todo para diferenciar el ámbito privado del profesional.

Creo que el teletrabajar constantemente requiere de una disciplina muy grande, porque es muy fácil distraerse con tareas “domésticas” y que tu productividad se resienta.

Otro problema es la socialización. Recuerdo haber leído la experiencia de una chica que teletrabajaba y estaba deseando que llegase el mensajero para tener a alguien con quien hablar un rato.

Indudablemente el teletrabajo aporta beneficios, sobre todo para las personas que tienen un trayecto muy largo hasta el trabajo. Yo normalmente hasta la oficina he tenido siempre sobre una hora, en el mejor de los casos 45 minutos y en el último trabajo tenia solo 20 minutos, eso si en coche en vez de trasporte público, y la verdad es que la calidad de vida es mucho mejor.

O también para conciliar la vida laboral y la familiar, para por ejemplo poder llevar a los críos al cole, etc.

Siempre me ha parecido un concepto, el del teletrabajo, muy interesante, pero muy peligroso, de los que si lo haces mal, te puede salir realmente mal.

Lo que si que creo es que hay que ir estando preparado para poder teletrabajar, en algún grado. Cada vez la tecnología es más accesible, con portátiles, vídeo y audio conferencias asequibles, etc. Igual no haces un teletrabajo puro, pero puedes facilitar que la gente trabaje, por ejemplo en una visita al cliente, o reduciendo viajes innecesarios con videoconferencias, o pudiendo tener factorías en otros lugares más baratos, o que te permitan acceder a personas con el perfil adecuado para tu proyecto, etc.