Blog

Pues resulta que después de 12 años con el dominio albergado en un proveedor americano, de Nueva Orleans para más señas, decidí hace unos meses pasarlo a un proveedor español.

Originalmente estaba en USA, porque por el año 2001, que es cuando lo compré, no había ese tipo de servicio por aquí. Pero hoy día si lo hay y prefiero que me atiendan en mi idioma, y darle las «perras» a alguien más cercano. Cuando trabajaba en Bilbao, pasaba todos los días delante de sus oficinas.

El traspaso ha sido un poco problemático como ya comenté . Hay varias lecciones aprendidas.

• Si quieres traspasar un dominio americano (.com o .net) estate seguro de que tienes deshabilitada la protección contra robos, sino no vas a poder traspasarlo. 
• Hazlo con tiempo, yo lo hice con un mes de antelación antes de que me caducase y aun así me quedé sin la redirrección durante diez días.
• Te tienen que pedir un AuthCode, para verificar que tu eres el dueño.
• Para comprobar como están los DNS en Linux hay una herramienta que se llama whois, que hace las consultas a los registros. También es útil el usar el nslookup para realizar consultas a los DNS directamente.

Existe la posibilidad con Blogger de redirigir tu nombre de dominio (www.inigoserrano.com) a tu blog sin tener que andar con trucos como los frames. La opción la tienes en el menú configuración, opción Básica.

Así que me he pegado un poquito estos últimos días con DNS y demás.

Una de las cosas que más me preocupa a la hora de industrializar un desarrollo de software es la actitud de los compañeros. Es algo que va a marcar decididamente el devenir del proyecto. Herramientas de ticketing, Auditorias de código, herramienta de pruebas funcionales y demás artillería no sirve de gran cosa si las personas involucradas en el proyecto no tienen la actitud adecuada. Actitud que es muy difícil de tener en estos tiempos de crisis.

He encontrado un artículo muy interesante sobre como sobrevivir a un jefe difícil. Iba a ponerlo simplemente como una entrada en twitter y en linkedIn, pero me parece que es lo suficientemente interesante como para darle algo más de entidad y dedicarle esta entrada del blog.

Leyéndolo me ha recordado algo que me enseño un antiguo jefe, el intentar ponerse en la situación del otro para intentar entender porqué hace lo que hace. Suele dar buenos resultados.

Es muy tentador el quedarse solo en echarle las culpas de los problemas a otro y no intentar hacer algo de autocrítica, aunque sea de forma privada. Por experiencia se que si las cosas van muy mal normalmente no hay un solo culpable, suele haber más de uno.

Uno de los objetivos de las entradas del blog referidas a la industrialización del desarrollo es poder compartir vivencias que puedan servir a otras personas para entender mejor como funciona un proyecto de desarrollo que tenga un cierto tamaño. Estás son mis vivencias, si las contrastas con tus propias experiencias y las de otras personas, podrás sacar tus propias conclusiones, y te enriquecerás. Como habrás podido comprobar muchas veces hago referencia a otros compañeros, jefes o no, que me aportaron sus puntos de vista. Unas veces esas opiniones me convencieron y las incorporé a mi «mochila» y otras no. Creo que es bueno escuchar a los jefes, o a compañeros con más experiencia, ya que ya han recorrido el camino por donde tu estás transitando.

Una de las cosas a las que más atención presto cuando tengo que diseñar la arquitectura de una aplicación o plantear la industrialización de un desarrollo es el gestionar la capacidad de la gente. No todo el mundo tiene la misma capacidad de «coco», pero si que hay una cosa cierta, nadie la tiene infinita. Así que hay que pensar muy bien con que cosas quieres llenarla.

Normalmente, independientemente de la capacidad natural de cada persona, con el tiempo esa capacidad se va aumentando, porque ya vamos teniendo cimientos sobre los que asentar los nuevos conocimientos.

Como he comentado en alguna otra entrada, llevo en el mundillo del desarrollo de webs con Java, de cuando eran webs y no aplicaciones lo que se hacían. Así que he visto como se ha ido complicando todo. Todavía recuerdo en uno de los primeros proyectos de envergadura en los que participé como un compañero me decía, que para que me preocupaba tanto por el código, si no lo mira nadie.  Hoy día casi todo el mundo tiene controles da calidad en el código.

Alguna vez comentando con compañeros de trabajo sobre estos temas, ponía de relieve que a los programadores se les empezaba a exigir saber de Java, JavaScript, Html, Bases de datos, etc y encima con auditoria de código, normas de base de datos, normas de usabilidad, etc, pero luego se les daba nada de tiempo para que hiciesen el mantenimiento en cuestión.

Así que siempre intento dejar las arquitecturas de las aplicaciones o las metodologías de trabajo lo más sencillas posibles. Recuerdo una presentación que vi en Internet de la arquitectura de Pinterest, en la que recomendaban justo esto mismo. Decían que mejor dejar la arquitectura lo más sencilla posible, porque siempre acabará fallando y cuando más sencilla sea más fácil será de arreglar. Explicaban la arquitectura que habían ido siguiendo ellos y como tuvieron que simplificarla.

Me ha sorprendido lo simple que es la arquitectura de desarrollo que se propone en el Google App Engine. No hay capas y más capas de servicios. Es todo mucho más plano.

Me he dado cuenta también de la cantidad de cosas que hacemos sin reflexionar, dejándonos llevar por lo que se hace en el mercado, sin ser un poco críticos con ello. Montamos arquitecturas aplicando mil patrones para dotarnos de una flexibilidad que luego en la mayor parte de las veces no usamos. Pero lo que si que encarecemos es la creación de las aplicaciones.

Recuerdo en una de las empresas en las que trabajé que se tenia una arquitectura de hacer las aplicaciones en las que se tardaba unos 5 días por mantenimiento, hasta que se marchó la persona que definía esas cosas y le pudimos meter mano. Aligeramos la arquitectura y se dejó cada mantenimiento en 4 días. Habíamos bajado un 25 % el tiempo de desarrollo en cada mantenimiento. Simplemente quitando flexibilidad que no servia para nada.

En este negocio del desarrollo de aplicaciones, cuando te enfrentas tanto a la definición de Arquitecturas Web, como a la Industrialización del desarrollo hay multitud de herramientas y de técnicas disponibles.

Supone un trabajo ingente el valorar y monitorizar la evolución de tal número de herramientas. Yo desde hace mucho tiempo he optado por una estrategia que me ha dado buen resultado.

Normalmente suelo monitorizar algún sitio de referencia para estar al tanto de las novedades que van surgiendo y cuando sale alguna herramienta o tecnología que no conozco y está en el área en el que me muevo le echo un vistazo, para estar al día.

He tenido compañeros que aparte de ir al web y enterarse a nivel teórico, incluso hacían una prueba por ellos mismos. A mi esto me parece dedicar mucho esfuerzo a conocer las interioridades de algo que no sabes si vas a llegar a necesitar en algún momento. Yo prefiero quedarme con el nombre de la herramienta y para que sirve y si en algún momento necesito esa funcionalidad recuperar la información y si procede probarlo, pero ya con un objetivo concreto.

Últimamente sigo bastante a Google, que aparte de tener una multitud de servicios para usuarios finales también tiene una sección de desarrollo con multitud de herramientas, guías, etc.

Son los que tienen la nube más grande y sus productos están diseñados para soportar una carga de trabajo muy alta.

Normalmente no vas a necesitar esos niveles de rendimiento, pero está bien ver como lo han resuelto ellos, para tomar ideas.

Cuando hablamos de industrializar, lo normal es que se nos venga la cabeza la típica imagen de una fábrica de coches, en contraposición a cuando hablamos de la artesanía, en la que lo normal es que se nos venga a la cabeza la imagen de algún orfebre, una encajera, etc.

La principal diferencia es que en la industrialización hay implicadas más de una persona y en la artesanía normalmente solo una.

Uno de los puntos que van a marcar la diferencia en la industrialización es lo ajustado que estén todas las personas involucradas y en lo afinado que esté el procedimiento de trabajo.

Negociar

Hoy quiero comentar respecto a la industrialización del desarrollo la importancia de la negociación y el saber delegar. Ambos son actitudes muy importantes para lograr que la maquinaria de producción vaya fina (No producimos coches ni lavadoras, pero si programas).

En mi vida profesional he tenido jefes y personas a mi cargo de todo tipo.

Con los jefes, hasta los más intransigentes, he procurado negociar las tareas. Digo negociar, no regatear. Me explico.

Puede ser que tu jefe te pida realizar alguna tarea o bien que tu mismo le propongas algún tipo de mejora. Entre dos personas puede suceder que haya un entendimiento a la primera, con lo que no hay nada que negociar, o bien que no lo haya. En este caso lo ideal es que cada uno de sus argumentos para intentar convencer al otro de la bondad de sus planteamientos. Puede ser que uno convenza al otro. Si esto no es así al final se aplica la jerarquía. Cada uno tiene su parcela de responsabilidad, por la que tiene que rendir cuentas, y consiguientemente su autoridad correspondiente. Así que normalmente no es una negociación muy larga.

Recuerdo una conversación que tuvimos un par de compañeros con el jefe, en la que le comentábamos (bueno realmente le recriminábamos) sobre otro compañero, que a nuestro entender no estaba haciendo las cosas bien y nos estaba perjudicando seriamente. La verdad es que era un jefe muy tolerante, que nos dijo algo que me parece muy importante tener siempre en cuenta. «Yo creo que es mi obligación escucharos y tener en cuenta vuestras opiniones, pero al final el que tengo que tomar las decisiones soy yo, porque soy el que tengo todos los datos».

Una vez que se llega a un acuerdo, como he comentado en otras ocasiones, lo que queda es cumplirlo de la mejor forma posible, estés o no de acuerdo. Todo el mundo está en su perfecto derecho de pensar lo que quiera, pero no de hacer lo que quiera.

Es muy raro que alguien confíe en otro si una vez llegado a un acuerdo no lo cumple. Tuve un jefe que nos comentaba que a lo largo de la vida te vas rodeando de la gente que te funciona. Era en medio de una conversación sobre una serie de personas que no le estaban funcionando y que al final acabó despidiendo.

Hay un concepto que es primordial, tanto en tu profesión, como en la vida misma: Cumplir los compromisos

Si no cumples corres el riesgo de que te consideren poco fiable y eso es algo que no es para nada interesante.

Cuando quieres industrializar el desarrollo de software no siempre es fácil de cumplir los compromisos, ya que dependes, de muchos factores que escapan de tu control.

Hoy quiero hablar de uno de los elementos más determinantes, los compañeros, el equipo de trabajo. Con suerte compañeros con experiencia que saben como funciona el negocio y otras veces compañeros con poca experiencia.

Creo que es importante insistir a los compañeros con menos experiencia lo importante que es el hecho de cumplir los compromisos. Y que cumplir el compromiso global de entregar la aplicación se basa en el cumplimiento de todos los pequeños compromisos de cada una de las pequeñas tareas que se van encomendando.

Cuando se acerca tu jefe y te indica que tienes que realizar tal mantenimiento para tal fecha y dices «vale» o simplemente no dices nada, has contraído un compromiso. Puedes tener suerte y que tu jefe esté sentado cerca tuyo y tenga pocas personas bajo su responsabilidad y pueda estar haciendo un seguimiento cercano, para ver que tal vas. Pero puede ser que no sea el caso y no pueda estar (o no quiera) como una madre preocupándose de todo. Pero esta situación no hace que los compromisos desaparezcan, siguen ahí.

Yo he estado en ambas situaciones, siendo responsable de un grupo de gente y poder dedicar tiempo al seguimiento y en otras ocasiones no pudiéndoles dedicar tiempo a ese seguimiento.

En estas ocasiones de falta de dedicación aplico un criterio que me comentó un antiguo jefe: «Mientras no digas lo contrario asumo que todo va conforme al plan y si tienes algún problema levanta la mano y se te ayudará».

Concepto simple, pero ¡que difícil es de llevar a la práctica!. Con suerte te encuentras con compañeros que te avisan justo el día de entrega, cuando ya no tienes margen de maniobra. Sin suerte, tienes que ir tu a preguntar: oye esto que tenias que acabar hace dos días está acabado?

Yo por lo menos nunca me he enfadado con alguien que se ha encontrado con dificultades y ha pedido ayuda cuando ha notado que se atascaba. Otra cosa es que igual no se le ha podido ayudar. Pero si que me molesta mucho los que incumplen sus compromisos y no alertan, porque afectan al cumplimiento de los objetivos del proyecto.

Hay un colateral al tema de levantar la mano y pedir ayuda, y es cuando la gente recurre muy alegremente a pedir ayuda. Hay que tener en cuenta el hecho de que alguien te ayude significa que sumas más horas a la tarea, las tuyas y las de quien te ayuda, y aunque cumplas el plazo no cumples el coste. Y el compañero que te ayuda también tiene compromisos que cumplir y te está dedicando su tiempo.

Es difícil dar una regla de cuando levantar la mano y cuando seguir intentándolo por tus propios medios. Solo dos reflexiones. El plazo de entrega hay que cumplirlo, si ves que no vas a llegar, levanta la mano. A más levantes la mano más van a pensar que no vales para hacer ese trabajo… tu mismo.