Industrialización del Software, mi visión.

Llevo bastantes entradas hablando de la industrialización del desarrollo de software, pero en ninguna de ellas he dicho que es para mí, aunque algo ya se habrá ido adivinando, sobre todo cuando lo contrapongo a la artesanía.

Cuando estás en un proyecto pequeño, de una o dos personas, con unos requisitos bajos, normalmente se funciona como un artesano. Es decir, te ocupas de todo y es tu valía personal y tu calidad la que se ve reflejado en el producto que vendes. Esto es así tanto si haces una figurita como si haces un programa.

Cuando los proyectos son más grandes, de decenas de personas, esta forma de trabajar en la que cada uno hace las cosas según su criterio ya no sirve. Básicamente porque tu trabajo es una parte de un todo y el resultado final ya no va a depender tanto de tu valía personal y tu calidad, como cuando trabajas como un artesano, sino que aparte de esto va a depender de lo bien afinado que esté todo el equipo.

He comprobado en mis propias carnes que por muy bueno que tengas a uno en un equipo, si el resto no está a la altura el proyecto no marcha bien. Es como si una maquinaria de un reloj tuvieses una pieza muy buena, pero el resto no. El reloj no marchará bien. Tampoco lo hará si las piezas son buenas, pero no están bien ajustadas. También se suele utilizar el símil de la orquesta.

Por eso habréis podido comprobar que la mayor parte de las entradas referidas a la industrialización del desarrollo del software están dedicadas a las personas. Para mi es lo más importante, el poner más o menos herramientas lo único que hace es facilitar o mecanizar las cosas.

Para mi la industrialización del desarrollo de software es la definición de que es lo que pasa, es decir los procedimientos y herramientas asociadas, desde que una petición llega del cliente hasta que esa petición se pone en producción (o se descarta).

Entran multitud de elementos, desde la captura de requisitos, la asignación de tareas, planificación, desarrollo, verificación, traspaso, etc. Va muy en la línea de lo que serían la ISO 9000 y el CMMI, por citar algunas normativas.

Hay gente que considera la industrialización del desarrollo de software como la aplicación de herramientas estilo MDA (model drive arquitecture). Para mi esto no es industrialización del desarrollo, es automatización del desarrollo. Es decir es tener la super churrera, que te genera, ya no un trozo de programa, sino el programa completo. No digo que la automatización sea algo malo, solo que para mi son conceptos diferentes.

Auditoria de código, un arma de doble filo

Llevo utilizando herramientas de auditoria de código desde hace más de diez años. Concretamente el PMD y Checkstyle y durante un periodo de tiempo muy corto, el Together. Siempre he estado muy interesado en estos temas de hacer las cosas no solo que funcionen sino además procurar hacerlas bien.

En estos más de diez años he ido pasando por una serie de estadios con respecto a la auditoria de código. Inicialmente me parecía muy importante y ponía a mis proyectos una configuración con muchas reglas. Eran épocas en las que estos temas de cuidar la calidad no estaban muy en boga que digamos, así que era una especie de bicho raro.

Con esas configuraciones tan exigentes aprendes una cosa, que si te pasas poniendo reglas no eres capaz de pasar del hola mundo. Y no siempre acaba compensando la mejora de la calidad con el incremento de coste.

Así que empiezas a aligerar las reglas, haciendo una selección más racional.

Poco a poco afortunadamente estas herramientas se han ido popularizando y cada vez más clientes para los que he trabajando lo han ido exigiendo.

Pero cuando extiendes estas herramientas a todo el proyecto te empiezas a dar cuenta de la dificultad y del lado oscuro de las mismas. 

El que no tiene criterio para hacerlo bien, no lo hará por mucha herramienta que le pongas. He visto a programadores arreglar errores dejándolo objetivamente peor, pero eso si había desaparecido la alerta.

Esto ocurre por un motivo, estas herramientas no solo detectan errores, sino que detectan patrones sospechosos, por eso hay que tener cierto criterio.

Hay que dejar las cosas sencillas. Algunas empresas para las que he trabajado tienen definidas reglas de auditoria de código en las que el pasar o no el criterio no solo depende del nivel de error sino de cuantas alertas tengas. Es decir por ejemplo el tener un número determinado de alertas de nivel Info puede hacer que no pases el criterio.

Este planteamiento es entendible, en el sentido de que una cosa que igual no está mal, pero se repite mucho puede ser una fuente de problemas. Por ejemplo si usas mucho las conexiones a base de datos, puede ser que cierres todas correctamente, pero es un punto de riesgo.

Este planteamiento puede resultar un poco complicado de hacer cumplir a un equipo de trabajo, porque no saben si lo tienen que cambiar o no.

Yo suelo preferir, siempre y cuando el cliente no tenga sus propias reglas, obviamente, planteamientos más sencillos. Los errores son eso errores y hay que arreglarlos si o si, y el resto de cosas, warnings, info, etc es opcional el arreglarlos.

Una de las cosas que si suelo incorporar a las reglas de auditoria son todas aquellas reglas que aunque no son importantes si son automatizables por los entornos de desarrollo. Por ejemplo el hacer que los if lleven siempre llaves.

Que le pido a un control de versiones: Acceso sin cliente

No siempre que necesitamos acceder a un fichero que se almacena en una herramienta de control de versiones tenemos un cliente en el dispositivo desde el que queremos hacer la consulta, o simplemente, no queremos obtener todo el contenido para solo hacer una comprobación puntual.

El poder disponer de un acceso mediante el navegador web puede suplir esta necesidad de consulta puntual.

En este aspecto casi todas las herramientas modernas disponen de esta posibilidad, de una forma más o menos fácil. Así que no hay un claro ganador en este apartado.

Elección de palabras: Factoría de Software vs Industrialización del Desarrollo

Cuando me plantee que es lo que hacía, a que me dedicaba, me vinieron a la cabeza dos conceptos: la industrialización del desarrollo de aplicaciones y la arquitectura de aplicaciones Web, mayormente con tecnología Java.

Y ese es el resumen del blog y los criterios que uso para etiquetar las entradas.

Pero me estoy planteando si he escogido bien las palabras. Me explico.

Si buscas en google por industrialización del desarrollo aparecen una multitud de entradas, ninguna de ellas relacionadas con la informática. Tiene sentido, ya que industrialización es un concepto que está más ligado a la época en la que se pasó del trabajo en el campo al trabajo en las fabricas. Y el concepto de desarrollo está más ligado a ciertos países en vías de desarrollo, etc.

Con tal cantidad de información en Internet asociada a estos dos conceptos es casi imposible que yo pueda aparecer en una posición en el listado a la que alguien llegue alguna vez.

Hay un concepto que es similar sobre el que si aparecen en las primeras posiciones de google entradas relativas a temas informáticos. Es el concepto de Factoría de Software.

La relación para mi es clara. La factoría de software es el destino, la industrialización del desarrollo de software es el camino.

Lo que todavía no he encontrado son las palabras adecuadas para la arquitectura Web.

Que le pido a un control de versiones: Backups

Una de las funcionalidades que creo que están bien en un control de versiones, aunque no es que sea primordial, es el facilitar el tener una copia del código en el servidor, de tal forma que si se estropea el disco duro de tu ordenador no pierdas todo el trabajo que has realizado.

Muchas veces se utilizan los comits en el servidor a modo de backups, pero esto no debiera de ser así, un comit debiera de representar un trabajo terminado. El disponer de una copia de seguridad hace que sea más fácil el mantener los comits como lo que son.

Aquí la única herramienta de las que conozco que realiza de forma nativa esto es Rational Team Concert. El resto no tiene ese soporte.

Bien es cierto que se podría realizar el backup dentro de la política de copias de seguridad de todo el equipo, no solo del código. Pero esas políticas suelen ser un poco precarias.

Comparativa de frameworks web

Empece en esto del desarrollo de webs con Java, cuando no había más que los servlets. Luego vino los JSP, los EJB, el Struts, etc.

Es curioso cuando ves que en una comparativa en la que uno de los «frameworks» que más rendimiento tiene son los simples servlets.

Como comenté en otra entrada, quizá debiéramos de plantearnos el simplificar las cosas.

También me ha llamado mucho la atención la simplicidad en el servidor de los planteamiento del GAE

Reputación

Cuando se habla de marca personal, se habla de la imagen que dejas o que quieres dejar en las personas que te rodean, bien a nivel personal, bien a nivel profesional.

A veces hay gente que comenta que la exposición a las redes sociales e Internet hace que te puedan difamar o que salgan a relucir tus fracasos. O peor, como un familiar que le andan suplantando la identidad en las redes sociales…

Andrés Perez, sugiere que como eso no se puede evitar lo que se puede hacer es enterrarlo, es decir generar más información positiva que acaba ocultando en los buscadores la información que te puede perjudicar. Esto puede ser una estrategia válida, pero creo que puede llegar a ser costosa.

Lo que si estoy de acuerdo con Andrés es en que lo fundamental para una marca personal es la fiabilidad. Es decir, una persona (marca personal) puede equivocarse, pero nunca mentir. Si te pillan mintiendo se acabó tu reputación.

Hay personas que son maestras en la manipulación, y conozco algunas, pero casi siempre acaban siendo descubiertas y su carrera profesional empieza a verse comprometida.

Yo siempre he procurado trabajar con dos criterios, y no creo que me haya ido mal: honestidad y no metiéndome en lo que no me llaman, es decir, conociendo lo que se me da bien y lo que no y lo que me gusta y lo que no. (Lo malo es que a veces no te metes sino que te meten…)

Eso no significa que no me he equivocado nunca. Este sector de la informática es bastante peliagudo, porque hay muchas variables que no puedes controlar, con lo que a veces incluso con la mejor de las preparaciones las cosas no salen bien. A mi eso no me obsesiona. Intento que las cosas salgan bien, porque es bueno para mi, pero como ya estoy curado de espanto, por sitios que aunque he puesto todo mi empeño las cosas no han salido bien, lo que hago es relativizarlo. Procuro ser autocrítico y tener la conciencia tranquila con mi trabajo.

Como me comentó un antiguo jefe, su médico le dijo que había aprendido medicina matando a unos cuantos… en la guerra civil, porque había muy pocos medios.

Otra de las cosas que he aprendido es que es imposible contentar a todo el mundo, da igual lo que hagas, siempre habrá alguien al que le parezca mal lo que haces. Es como en una charla sobre seguridad e higiene en el trabajo a la que asistí, en la que el ponente nos comentó que se habían hecho estudios sobre la temperatura del aire acondicionado y daba igual que temperatura pusieses, siempre había un 10% de gente que no estaba a gusto.

Lo que si es importante es que si quieres ser la opción preferente la gente te vea como alguien fiable.

Que le pido a un control de versiones: Trazabilidad

Trazabilidad. Creo que es la madre de todas las características de un control de versiones.

Es la capacidad de poder identificar que código corresponde con cada petición que te han realizado, normalmente en algún sistema de ticketing, como Bugzilla, Mantis, etc.

Cuando tienes que realizar un traspaso el poder saber que tareas tienes que traspasar y tenerlas perfectamente reflejadas en la herramienta ayuda mucho.

Aquí nuevamente el que mejor lo hace es Rational Team Concert. No hay que hacer ningún esfuerzo para tenerlo, viene de serie, además con una característica añadida y es la posibilidad de forzar administrativamente que todos los «commits» lleven obligatoriamente asociado una tarea dentro del ticketing.

Otro que lo hace relativamente bien también es el Git, ya que dispone de muchas facilidades para realizar ramas y mergeos.

El resto de los que conozco (VSS, CVS y SVN) no destacan tanto en esta funcionalidad

Bandoleros

He leído un artículo de Arturo Pérez-Reverte. Puede parecer que no tiene nada que ver con el trabajo de un informático. Pero describe una situación que me he encontrado en más de un lugar en el que he trabajado: los bandoleros (de bandos), el sectarismo, el o conmigo o contra mi.

Como he dicho, he vivido en varios sitios el formase grupetes de gente. Hasta ahí es normal, todo el mundo tenemos más o menos afinidad con ciertos compañeros.

El problema viene cuando esos grupos se convierten en sectas, con su líder supremo y su legión de seguidores que no se cuestionan al líder.

Cuando ves la endogamia de esos grupos, que prefieren poner a alguien de los suyos que no está preparado en absoluto en vez de a otra persona más adecuada.

Cuando ves a esa gente poner a bajar de un burro a compañeros que hacen su trabajo perfectamente simplemente porque no son de su secta. Parece que si no eres de su secta, entonces eres de los enemigos.

Pero no es así. Como dice Pérez-Reverte, no tengo ideología porque tengo biblioteca. Es decir soy capaz de pensar por mi mismo.

Me he encontrado en situaciones un poco delicadas, en sitios en los que las cosas no iban muy bien. Situaciones delicadas porque, por decirlo de alguna manera, he sido lo que se da en llamar un cuadro intermedio. Es decir para los «jefes» no soy del todo de los suyos, y para los «curritos» tampoco. Lo fácil en estos casos es decirles a cada uno lo que quieren oír, que los del otro bando tienen la culpa de todo.

Pero la experiencia me ha enseñado que cuando las cosas van muy mal, normalmente no hay un único culpable, suele ser un cúmulo de errores de varias personas.

Ese es el problema, si en vez de ir a cada bando a decirles lo que quieren oír vas diciéndoles que hay cosas que crees que están haciendo mal. Porque entonces si que te consideran definitivamente del otro bando.

Es muy importante cuando las cosas van mal, en vez de echarle la culpa al otro, hacer un poco de autocrítica y ver en que puedes mejorar tu las cosas. Si cada uno mejorase un poquito se notaría mucha mejoría.

Pero como la culpa es del otro bando para que voy a hacer nada.

Lo que no nos damos cuenta, es que un proyecto que vaya mal va a repercutir en nuestra percepción profesional, es decir en nuestra marca personal. Si una persona en todos los sitios en los que ha estado ha acabado en desastre, pues igual no tiene la culpa, pero que casualidad… mejor coger otro candidato…

Que le pido a un control de versiones: Flujos

Hoy vamos con una característica que me gusta tener en los controles de versiones y que hace muy bien el Rational Team Concert y es la definición de flujos.

Es decir poder tener definido que, por ejemplo, de una rama de trabajo se pasa a una rama de integración y de esta a una rama de Preproducción, etc.

Esto te permite tener definido y reflejado tu flujo en la propia herramienta, sin tener que andar definiendolo en una normativa en papel que se puede ir saltando a discreción.

En Rational Team Concert de hecho existe el concepto de flujo en el que puedes definir de un Stream (para entendernos una rama) a donde puedes liberar el código.

Otra herramienta que lo hace bastante bien es Git, sobre todo por la posibilidad de tener diferentes repositorios remotos y la posibilidad que te proporciona el gitFlow. Este añadido a Git te define un flujo típico dentro de la propia herramienta. Bueno siempre y cuando utilices SourceTree.

El resto de herramientas de control de versiones con las que he trabajo como Visual Source Safe, CVS y Subversion no disponen de estas funcionalidades de forma nativa, así que los flujos los tienes que hacer tu a mano. Lo cual es más tedioso y propenso a errores.