En El Libro Negro del Programador se insiste mucho (como en cualquier otro libro que nos enseñe a ser mejores profesionales) que la refactorización de código no es sólo una herramienta que debemos usar sino que ésta es un hábito que emplear en el día a día y que distingue a los mejores desarrolladores de software.

No obstante, el concepto de refactorizar se suele entender exclusivamente como un trabajo de modificar líneas de código y mejorarlo sin afectar a su comportamiento externo; conseguimos, efectivamente, limpiar en cierta medida el código para que sea de mejor calidad, más legible y mantenible.

Siempre insisto en que esto no es algo que se hace o no, sino que forma parte del hecho de programar una solución, es algo consustancial a la misma.

Cuando terminamos de implementar una nueva funcionalidad, siempre nos debemos preguntar ¿podemos mejorar lo que hemos implementado en algún aspecto?, ¿se puede simplificar?, ¿se puede mejorar en relación al proyecto general como parte que se pueda reutilizar?, etc. Lo sorprendente es que cuando te creas el hábito de plantearte este tipo de cosas apenas termina haciendo falta hacerlo al final de implementar algo, ya que tienes el hábito de hacer las cosas limpias desde un principio de modo que al final, es esfuerzo o tiempo que empleas como puro trabajo de refactorizar es mínimo.

No obstante, se suele entender por refactorizar el trabajo de mejora del código, pero ¿qué ocurre con la misma estructura de un proyecto que va creciendo y creciendo con el tiempo? No hablo de diseño, sino de cómo están organizadas las carpetas, subproyectos, etc.

Cuando un proyecto crece en tamaño (en forma de librerías dispersas, multitud de sub-proyectos, demasiadas dependencias externas, incluso una estructura de los proyectos de pruebas compleja) se debe y tiene que refactorizar igualmente.

Recientemente hemos cerrado una nueva revisión de uno de los proyectos en los que trabajamos actualmente (la Plataforma de Telegestión y MDM IRIS para dispositivos de telemedida PRIME). Pues bien, he planteado unos días de trabajo para mejorar la estructura interna del mismo para evitar que sea cada vez más compleja (de gestionar y de trabajar sobre ella).

En concreto, algunas de las cosas que vamos a evaluar son:

  • Unificación de algunas librerías dispersas que podrían vivir en un único proyecto.
  • Integración de algunos subproyectos pequeños que podrían vivir coherentemente en otros.
  • Mejora de la distribución y estructura de las puebas de integración.
  • Plantear las bases para que el gestor de tareas, ahora muy ligado a la idiosincrasia de la solución, viva como un framework independiente del proyecto (y reutilizable por otros proyectos que pongamos en marcha).
  • etc.

¿Qué pretendo conseguir con esto?

Cuando un proyecto crece en complejidad, cuando hablamos de cientos de miles de líneas de código, aunque esté todo realizado con extremada limpieza y con una arquitectura general y microdiseños muy cuidados, la misma distribución de los artefactos del proyecto puede ser un problema que impida llegar a los sitios con sencillez y comodidad. La espaguetización del proyecto no sólo se puede producir en su código sino también en la estructura misma de sus módulos.

De este modo, al mejorar y simplificar cómo están distribuidas y organizadas las cosas, ganamos agilidad y comodidad a la hora de trabajar en una nueva revisión. Lo que no es fácil de ver es que esta agilidad y comodidad se traduce después en ahorro de muchas horas de trabajo. Coseguimos la máxima calidad en algo cuando tenemos un entorno cómodo de usar y de trabajar. La facilidad de mantenimiento también tiene mucho que ver con esto.

Detrás de cada acto de refactorización, del tipo que sea, se esconde un ahorro de tiempo futuro al dedicar menos esfuerzo y tiempo en evolucionar una aplicación bien hecha, o lo que es lo mismo, el tiempo invertido en refactorizar se traduce en una mejor productividad (= menos recursos económicos necesarios para hacer algo).

Me sorprende a menudo cómo los desarrolladores de software nos complicamos la vida por no dar un paso atrás e identificar aquello que nos impide centrarnos en escribir código de producción y testearlo. Los problemas casi siempre surgen de no montar en entorno adecuado de pruebas que permita testear la nueva funcionalidad que incorporamos con comodidad. El extremo más radical de esto consiste cuando la única posibilidad de probar algo es ¡en el entorno de producción del cliente!. Me temo que sólo mecionarlo se me pone la piel de gallina, aunque lamentablemente lo he vivido y lo he visto en varias ocasiones.

Cuando comienzo un nuevo proyecto, aunque sea sencillamente probar una tecnología que desconozco y con la que comienzo a jugar, lo primero que hago es montar un entorno en el que trabajar con absoluta comodidad: si no lo hacemos así, a los problemas habituales de resolver errores y avanzar en aquello que no conocemos bien le añadiremos los inconvenientes de trabajar con ese entorno incómodo (o lo que es lo mismo, perderemos más tiempo en problemas con el entorno que en crear software útil).

Por poner un ejemplo, últimamente estoy haciendo algunas pruebas de concepto implementando algunos módulos en node.js que acceden a un servidor MongoDB. Lo primero que he hecho ha sido instanciar una máquina virtual con un Ubuntu Server en el que arrancar MongoDB; una vez que aprendo a limpiar completamente todas sus colecciones y realizar las tareas de administración básicas y suficientes para las pruebas que quiero implementar, todo lo demás lo puedo realizar mucho más rápidamente y cómodamente y, sobre todo, en pocos pasos.

Esto parece una trivialidad, pero si no lo hacemos así y estas operaciones elementales no las hiciera con sencillez, me resultaría muy complicado avanzar en las pruebas de node.js que estoy realizando: terminaría hastiado y acabaría abandonando más pronto que tarde.

El pricipio que me encanta aplicar en esto es aquel que indica que para las tareas repetitivas, sólo deberíamos trabajar una vez.

Efectivamente, sólo dedico algo de tiempo al comienzo para crearme un entorno de trabajo lo suficientemente cómodo como para poder centrarme en las pruebas o lo más importante del trabajo que me propongo realizar.

No hace mucho terminé de leer un libro que me ha encantado; se trata de El Efecto Compuesto de Darren Hardy (se puede encargar en español aquí), sobre cómo los pequeños hábitos y las pequeñas acciones, mantenidas en el tiempo y con constancia, representan realmente una gran diferencia.

Del mismo modo, ¿como sería nuestro trabajo si cada vez que quisiera ejecutar la prueba X necesitara pasar cinco minutos limpiando una base de datos, levantar ciertos servicios, etc.?, ¿cuánto tiempo perderíamos al usar un editor que no dominamos del todo?, ¿cuánto tiempo perdido si tuviéramos que probar algo leyendo el resultado en un documento txt?.Para ser productivos escribiendo el código de producción en el que trabajamos tenemos que crearnos entornos sencillos y eficientes, lo que requerirá seguramente dedicar algo de tiempo la primera vez que se genera ese entorno, aunque esa pequeña inversión de trabajo y tiempo la rentabilizaremos con creces posteriormente.

De nuevo, vemos cómo un buen y profesional desarrollador de software, competente en su ámbito, con suficiente experiencia, no llegaría al 10 si no se rodea de hábitos y condiciones que permiten que su trabajo se haga con comodidad y eficiencia.

Una nueva fase

Un artículo de Rafa G. Blanes

Después de año y medio, ya está disponible el libro completamente revisado y reeditado en todos los sites de Amazon, tanto en papel como en formato Kindle.

Me han preguntado recientemente que qué se puede esperar de El Libro Negro del Programador: muy resumidamente siempre digo que ojalá hace ocho o diez años alguien me hubiera hecho notar o advertido sobre ciertos aspectos del desarrollo de software, no necesariamente técnicos, porque se da la circunstancia de que cuando un proyecto falla, casi siempre lo hace por las mismas razones: mal talante técnico, desastre organizativo y de planificación, equipos no coherentes, falta de un mínimo de metodología y un largo etcétera, pero casi siempre son las mismas circunstancias.

En ocasiones veo que ciertos desarrolladores de software más que programar bien, tratan de jugar chapuceramente con lo que hacen. Debemos y podemos ser profesionales buscando la calidad de nuestro trabajo al tiempo que lo hacemos lo más lúdico posible. En este sentido, y parafraseando un capítulo del libro MBA personal de Josh Kaufman, para progresar en nuestras carreras debemos tratarnos y gestionarnos como si fuésemos empresas: nuestro mejor activo somos nosotros mismos, siempre buscando ofrecer y hacer un trabajo de calidad.

¿Y a partir de ahora qué?

En el libro se han incluido varios capítulos inéditos; uno de ellos es el Test del Desarrollador de Software Altamente Productivo, en donde se identifica mediante un juego sencillo de preguntas, qué hacemos bien y no tan bien para trabajar productivamente (es decir, no perder el tiempo, que es nuestro único activo de valor y conseguir más y mejores resultados). En los próximos meses iré desarrollando todas esas preguntas, al menos las más relevantes, en el blog de El Libro Negro del Programador, entre otras cosas.

Espero de verdad que os sea útil este trabajo.

Los principios de trabajo "lean" me entusiasmaron desde el primer momento en que tuve conocimiento de ellos. El desarrollo ágil viene de la aplicación en cierta medida de los principios de desarrollo lean y guarda muchas similitudes con estos principios. Como todo, si algo es simple, fácil de entender y sencillo de poner en práctica y de sentido común tiene el éxito garantizado. No obstante, me sorprende cómo muchos de estos principios son totalmente desconocidos para muchos desarrolladores de software y emprendedores de cualquier naturaleza.

El Libro Negro del Programador ha sido escrito siguiendo algunos de los principos lean y su finalización (en el momento de escribir esto está en fase de edición) ha sido posible por y gracias a esta metodología.

Muy pero que muy básicamente, la concepción lean en el desarrollo de un proyecto nuevo y emprendedor viene a indicar que no podemos esperar al final del mismo para comprobar si va a tener éxito o no. ¿Cómo puedo averiguar si una idea genial que he tenido puede convertirse en un éxito comercial? Uno de los errores de muchos emprendedores es volcar todo el esfuerzo, tiempo y dinero en terminar algo completamente antes de lanzarla y después esperar (y rezar) para comprobar si tiene buena acogida o todo lo contrario. En ocasiones cuando se llega al final ha pasado tanto tiempo que la genial idea ya ha sido superada por otras en el mercado, o bien se pule y refina el proyecto tanto que se sufre de parálisis por análisis.

Una de las historias fascinantes que cuenta Eric Ries en El Método Lean Startup es la del dueño de Groupon, actualmente una multinacional con presencia y servicio en multitud de países para el intercambio y promoción de cupones de descuento. Desde luego no invirtió en crear toda la infraesctutura actual de Groupon para ponerse en marcha, sino que comenzó muy humildemente probando el concepto con sus familiares y amigos y, de ahí, según la respuesta obtenida, fue mejorando continuamente y dándole forma como proyecto empresarial. Convirtió una idea sencilla, práctica y barata de probar, en una compañía global.

Del mismo modo, desde El Libro Negro del Programador he ido compartiendo los avances de los capítulos para obtener feedback y comprobar el grado de interés que pudiera despertar un proyecto así. ¿No ocurre lo mismo que en software cuando le enseñamos a un cliente cómo se van implementado las historias de usuario para afinar en requisitos y su idea de lo que quiere y necesita?

Afortunadamente, desde los primeros capítulos, El Libro Negro del Programador despertó suficiente interés como para perserverar en su avance, en forma de correos de ánimo, mensajes sobre erratas, sugerencia de nuevos capítulos, puntualizaciones, diversos puntos de vista, ayuda para revisar los documentos gramatical y ortográficamente (gracias Luis)  y, para mí lo más gratificante, preguntas del tipo "¿cuándo y cómo podré adquirir el libro?".

El método lean no sólo te ayuda a comprobar el interés en algún tipo de idea o proyecto, sino que te permite mejorarlo y afirnarlo mediante una táctica de pivotar sobre la idea o perseverar en ella.

Estamos aprendiendo a hacer las cosas de otro modo, a emprender proyectos con otras tácticas; también la redacción de un libro se puede enfocar así.

Me he encontrado en ocasiones algunos desarrolladores de software que, al menos aparentemente, se obstinan en hacer las cosas exageradamente complicadas. Tanto es así que parece que lo hacen como seña de identidad: cuanto más abstruso más demuestro lo bueno que soy. Digo yo que lo mismo iban por ahí lo tiros.

No obstante, la pregunta que hay que hacerse cuando escribimos una nueva pieza de código es, "¿lo entenderemos nosotros mismos dentro de un tiempo?", si la respuesta es afirmativa, la siguiente pregunta sería "¿lo entenderán los demás, aquellos que hereden para lo bueno o para lo malo este trabajo?".

Yo siempre digo que si el primer objetivo de un buen software es resolver algún problema y que le sea de utilidad a alguien, lo segundo es que debemos programar para que los demás puedan asumir fácilmente aquello que hacemos. Nada más ingenuo que pensar que cuanto más rebuscado hagamos el trabajo mayor la estima técnica que nos puedan tener.

Un cosa clara me ha demostrado la experiencia, algo además irrefutable: las mejores soluciones con las que más me he sorprendido, han sido claramente las más sencillas. Todos podemos deliberadamente hacer algo complejo, pero pocos, muy pocos, podemos dar con el medio o la solución más sencilla.

Este debería ser uno de los prinpios con los que trabajar en el día a día: intentar buscar siempre la solución más sencilla a cualquier problema, tanto de programación, de diseño, etc.

No sólo este principio mejorará nuestros productos, nuestro día a día en el futuro cuando tengamos que volver a modificar una aplicación, sino que con el tiempo te das cuenta de que el hábito constante de buscar siempre simplificar las cosas, precisamente te reprograma la cabeza para que de manera natural te surjan soluciones sencillas.

Recomiendo encarecidamente la lectura (y relectura) del libro Code Simplicity, el libro de Max Kanat-Alexander, ingeniero software en Google en donde reflexiona sobre estos conceptos que tanto pueden hacer por mejorar la calidad del trabajo que realizamos. Su blog también contiene entradas muy interesantes.

¡Vamos llegamos al final del libro!

Después de más de un año dándole forma a El Libro Negro del Programador, ya es hora de darlo por cerrado y publicarlo oficialmente.

Como siempre he indicado a lo largo de los capítulos, su versión publicada en la web son adelantos: la versión final del libro tendrá los capítulos más desarrollados, con más ejemplos y además se incluirá una serie de capítulos inéditos, entre ellos el de conclusiones y uno que me gusta especialmente: el test del desarrollador de software altamente productivo.

Es sorprendente la cantidad de cosas que te planteas y re-planteas cuando escribes sobre los temas que te gustan y apasionan: una cosa es creer que sabes algo y otra muy distinta ponerlo por escrito para contárselo a otros, sobre todo de una forma que hasta tu abuela lo tendría que entender.

No sé si he tenido mucho o poco éxito, pero la motivación principal de El Libro Negro del Programador es la de allanar el camino a quienes llegan a nuestra profesión y a quienes llevan más tiempo pero que creen que han alcanzado todo lo que había que saber...

Si es verdad que aprendemos de los errores, en el libro tenéis los que desde mi punto de vista cometemos con más frecuencia los desarrolladores de software y que nos impiden trabajar con la excelencia como único propósito; porque lo que sí tengo más que claro es que la economía que viene no es la de la titulitis, sino la del talentismo, o como diría el gran Raimon Samsó, la clase emergente de los expertos.

En los próximos días se publicará un último capítulo y en unas semanas podréis disfrutar del libro editado con profesionalidad desde distintos portales en Internet.

Gracias y hasta pronto.

Software testingReconozco que comencé a tomarme muy en serio el ser más estricto con el desarrollo y refactorings de las pruebas desde hace relativamente pocos años. Efectivamente, me llevó su tiempo darme cuenta de la enorme rentabilidad metodológica al pasar de una aplicación de consola para depurar (...) que tener formalizadas correctamente una completa y contundente batería de pruebas. Tanto es así, que hoy día sólo veo a través de las pruebas, quiero decir, cuando desarrollo nuevo código de producción, pocas veces entro en él en modo depuración si las pruebas correspondientes indican que todo va bien.

No obstante, y sin caer en la simpleza de reconocer lo fácil que es detectar en qué otros fallan, veo a menudo (muchas más veces de las que me gustaría) que el hecho de tener implantantado una arquitectura y metodología que permite y exige el crear pruebas, éstas se desarrollan como para salir del paso, en lo que se suele en llamar el happy path y que yo llamo particularmente "pruebas felices".

¿Qué es una prueba feliz?. Cuando escribimos una nueva clase o añadimos una nueva funcionalidad a código ya existente, tenemos la tendencia natural de escribir pruebas que consciente o inconscientemente sabemos que van a dar pocos problemas. Probamos entonces el mejor caso y que resuelve bien nuestro código: la prueba feliz viene a decirnos que nuestro código hace bien aquello para lo que lo hemos desarrollado. No obstante, si nos limitamos a escribir exclusivamente pruebas felices, estamos ignorando gran parte del objetivo de tener una solución respaldada por tests. Buscamos sólo pruebas felices porque en realidad percibimos el escribir pruebas como un mal que hay que asumir en lugar de un pilar fundamental y esencial en el desarrollo de un software de calidad y profesional.

El objetivo de escribir pruebas no es sólo el de tener un mecanismo por el que poder comprobar automáticamente que algo funciona ahora y seguirá funcionando en el futuro. Escribimos tests no sólo para la situación ideal (el camino feliz) sino que debemos desarrollarlos para comprobar todas aquellas situaciones incómodas en las que una funcionalidad particular se podría ver comprometida. Se nos olvida en ocasiones que los tests persiguen detectar errores, si nos quedamos con los casos más sencillos, seguramente estaremos ocultando bugs que tarde o temprano nos explotarán en las manos.

¿Cuándo es el momento más oportuno para detectar errores y problemas?, ¿cuando estamos precisamente desarrollando una nueva funcionalidad o cuando el software está ya en producción con uno o varios clientes usándolo?. La respuesta es más que obvia.

Recientemente he desarrollado un servicio de Windows para instanciar ciertos servicios web que emulan el comportamiento de un tipo de dispositivo. Se simula uno de estos dipositivos instanciando sus servicios web correspondientes en un puerto específico. Desarrollé como es lógico ciertas pruebas para garantizar que los web services se instancian bien para el puerto 8000, ¿y ya está?. Absolutamente no, ¿qué pasaría si al desplegar ese software en una máquina en producción ese puerto está ya siendo usado?. En este caso, las pruebas tienen que garantizar que somos correctamente notificados cuando se da esa circunstancia, que un error de este tipo no provoca un crash completo del servicio de Windows, etc. Si me hubiera quedado en la prueba feliz, seguramente habría terminado antes, pero con toda seguridad en el futuro habría tenido que dedicar muchísimo más tiempo a solucionar ese tipo de errores en producción y con un cliente insatisfecho...

Esto no es más que un ejemplo pero es que a veces no nos damos cuenta de la cantidad de esfuerzo y tiempo que nos podemos ahorrar detectando errores en producción sencillamente creando una batería correcta de tests en la fase de desarrollo. Pocas cosas hay que tranquilicen más en software que saber que tu producto está tan suficientemente probado que muy difícilmente se van a encontrar problemas en el despliegue del mismo.

Una ley del software viene a ser que cuanto más y mejor pruebes un software, mayor lo vas a rentabilizar, en el sentido de dedicar menos tiempo a depurar errores, el tener menos clientes reportando problemas, etc.

Tampoco es cuestión de crear el mayor número de pruebas porque sí sino de crear éstas con la calidad suficiente y cubriendo todos los posibles casos.

Este es un asunto que, me temo, solemos subestimar y es que no es trivial crear y saber desarrollar pruebas con la suficiente calidad; el problema es que en nuestra profesión muy a menudo debemos tener un carácter polifacético (lo que viene siendo tener que hacer de todo un poco); este no es un tema sencillo sino que el tester es un claro perfil de persona cualificada con ciertas aptitudes en su profesión, como bien indica este magnífico libro de Software Testing.

A veces me he planteado la pregunta de cómo evaluar un buen software de uno que no lo es tanto. Aquí entran en juego seguramente aspectos muy subjetivos; sin embargo, si intentamos llegar a algún tipo de principio del tipo de los que muestra Max Kanat en su libro Code Simplicity, existen realmente varias maneras de evaluar la calidad de un buen software.

No me gusta nada ni siquiera plantear el concepto de calidad, ya que en la mayoría de las ocasiones, los desarrolladores de software hacen lo que pueden en el contexto laboral con el que les toca lidiar; pocas veces he visto que realmente las cosas se hagan mal por pura y llana pereza mental. Sí he visto muchas a menudo que las cosas se hacen mal por ingenuidad o por la falta de un tutor que sirva de guía y ganas de traspasar su experiencia.

¿Cómo entonces distinguir una librería o trozo de software bien hecho de otro no tan bueno?.

Un error muy común que cometen muchos desarrolladores de software es escribir código de manera que es difícil crear a su alrededor las suficientes pruebas o tests que garanticen que ahora y más adelante, el software funciona.

Esto es un mantra que repito a menudo: la estructura de una solución que puede ser probada no tiene nada que ver con la estructura de otra para la que es imposible crear un conjunto de tests. Por tanto, aquí tenemos un elemento que nos puede indicar en cierta medida la calidad de una pieza de código: si se puede probar con facilidad o dificultad.

Pero, ¿qué hay del mantenimiento?, ¿no es verdad que queremos escribir software que viva muchos años y que pueda ser vendido y desplegado en el mayor número de clientes posible?. ¿Cómo vamos a hacer esto si la solución que escribimos es imposible de mantener?. Volvemos a la metáfora del coche que no se puede reparar...

Del mismo modo que antes, un buen software escrito para facilitar su mantenimiento no tiene nada que ver en su forma y estructura de otro que es imposible o muy difícil de mantener (diseño rígido), entendiendo por mantenimiento la detección fácil de pequeños bugs y la capacidad de mejorar el producto con nuevas características o mejoras de las ya existentes.

Efectivamente, con el tiempo nos damos cuenta de que el diseño, estructura y forma de un software que permite ser probado con facilidad y que puede ser mantenido con sencillez, no tiene nada que ver con el diseño, la estructura y forma de un software que ni podemos probar bien y para el que es muy complicado introducir algún cambio.

Esto es un principio de desarrollo de software inquebrantable que uno termina por aprender a lo largo de varios años después de algunas etapas de fracasos y errores.

Cuando llegamos a este tipo de conclusiones, nos damos cuenta de que programar bien no se consigue sencillamente leyendo un buen manual de C#, Ruby on Rails o lo que sea; conocer los rudimentos de cualquier tecnología no es suficiente. Existen principios, leyes, diseños, etc. que nos indican realmente cómo llegar a una solución con la suficiente calidad.

Software quality¿Qué es lo que distingue un buen profesional de una persona que se gana la vida con aquello que le ordenan hacer?. Llevo mucho tiempo preguntándome qué es lo que realmente distingue a alguien por el que las compañías se pelearían en conseguir de aquellos que nada más entregar un currículum, éste va a parar a una enorme y creciente pila. Me temo que queda muy atrás el tiempo en que bastaba con decir tu título o profesión para convertirte en candidato: los paradigmas laborales están cambiando más rápidamente de lo que nos estamos dando cuenta.

No obstante, podemos esbozar un enorme y relevante corolario de logros en nuestra pasada vida laboral, mientras que sólo podemos ser verdaderamente profesionales en aquello que hacemos en el día a día.

Programadores, desarrolladores de software, aquellos en general que trabajan creando nuevas soluciones, sólo pueden prosperar de un modo, ni títulos, ni el soporte de grandes compañías en las que uno ha trabajado y nada de todo esto: somos profesionales cuando somos capaces de realizar un trabajo igualmente profesional.

Esto no es ninguna novedad, claro está, pero lejos de una actitud complaciente y egocéntrica que nos hace considerar todo lo que hacemos como lo mejor, tenemos que reconocer una cosa: hacer un trabajo pro requiere de una disciplina diaria que no tiene todo el mundo.

Me he encontrado en muchas ocasiones en la tesitura de tener que corregir detalles y bugs de compañeros, lo cual no está mal y forma parte de nuestro trabajo. Sorprende cuántas veces he descubierto cosas que manifiestamente se podrían haber hecho mucho mejor exactamente con el mismo esfuerzo.

Si cuesta el mismo trabajo hacer una cosa regular y hacerla de manera excelente, ¿por qué elegir la primera?. En muchos casos es sencillamente por pura pereza; en otros por que para exigirnos un nivel de excelencia en todo lo que hacemos se tienen que dar una serie de condiciones en el contexto en el que trabajamos.

No termino de entender cómo sabiendo hacer algo muy bien, por qué lo dejamos con un nivel de calidad pésimo si además nos cuesta el mismo esfuerzo. Un profesional esto lo tiene muy claro y es que la única métrica por la que se nos puede medir y valorar no es otra que la calidad del trabajo realizado. No hay más.

En el lugar donde trabajo llegan frecuentemente currículums y me sorprende que la mayoría de la gente no pone en valor la calidad de los trabajos realizados: casi siempre se ensalza el dominio de tal y cual tecnología, el haber trabajado en la renombrada empresa X, cuando en realidad lo que a un responsable de recursos humanos (o al menos es lo que yo mismo aplico) le gustaría ver algo como "Desarrollo de la aplicación tal actualmente en producción con tantos usuarios", "módulo X compartido en Github con tantos usuarios", etc. etc.

No somos profesionales por lo que decimos y ni siquiera por dónde trabajamos, sino por la calidad de lo que hacemos.

Lo sorprendente es que esta calidad en muchas ocasiones se consigue sencillamente eligiendo correctamene, a pequeños pasos y creando el hábito de hacer las cosas bien, obviando la pereza de terminar de cualquier forma, sin darnos cuenta de que así vamos dejando piedras que tarde o temprano se desmoronarán encima nuestra. No necesitamos participar en grandes y subvencionados programas de I+D para realizar cosas fantásticas (...): la mejor innovación se puede hacer cualquier día en el trabajo que estamos realizando. Si conseguimos como hábito que la excelencia sea la base de todo lo que realizamos, será entonces cuando irán surgiendo nuevas ideas, oportunidades de éxito y posibilidades para mejorar nuestra carrera profesional. Hacer, por lo contrario, un trabajo cutre, posiblemente nos permitirá pagar algunas facturas más, pero irá menoscabando nuestras oportunidades tarde o temprano.

Si aquello en lo que estoy enfrascado ahora mismo lo puedo hacerlo mejor, ¿por qué no hacerlo?. Un profesional se labra con el trabajo diario de muchos años.

Es recurrente la pregunta que me hacen según la cual siempre se pone en duda la necesidad de realizar software sencillo, fácil de entender (por nosotros y por los demás) pero sobre todo, mantenible. Muchos de quienes nos dedicamos a desarrollar software profesional no tenemos claro aún ciertos conceptos esenciales, como por ejemplo que un diseño matenible no tiene nada que ver con un diseño de algo que es imposible modificar, depurar, evolucionar, etc. Aun funcionando bien, el primero nos dará un mayor rendimiento del trabajo realizado, mientras que en el segundo caso el software pasa a producción moribundo y sin apenas solución de continuidad.

No obstante, nos cuesta reconocer la relación que existe entre la sencillez y la facilidad de mantenimiento.

Mantenible (palabra mantra en el Libro Negro del Programador) no significa trivial, que un principiante sin apenas esfuerzo pueda entender a la primera, sino coherente, un diseño eficiente que facilita los cambios en el futuro y que la adaptación a nuevos requerimientos relacionados son viables (a un coste asumible).

A diferencia del autor de un best-seller que cuando publica un libro que funciona bien recoge royalties según las ventas, cuando publicamos un producto software tendremos más o menos éxito si este puede evolucionar, si puede ser cambiado y fácilmente mantenido.

En Code Simplicity (libro que recomiendo aunque no se lea ni una línea de código) se pueden leer frases auténticamente reveladoras que el autor intenta sintetizar a modo de leyes comunes que gobiernan el desarrollo de cualquier software.

Una de estas afirmaciones que sostiene el autor es que la facilidad de mantenimiento de cualquier pieza de código es proporcional a la simplicidad de sus partes individuales ("The ease of maintenance of any piece of software is proportional to the simplicity of its individual pieces").

Cuando leí esta frase pensé que cuánto tiempo había intuido esta relación pero sin embargo había sido incapaz de sintetizarla de esta manera tan magistral. Una virtud tiene ese libro: sintetiza de una manera genial auténticas verdades que aún siendo sencillas de entender no lo es tanto de aprehender e introducir en nuestro adn de programadores profesionales.

Efectivamente, parece básico pero no es tan elemental tenerlo presente en nuestro día a día.

Si queremos hacer software mantenible, la clave está en conseguir que cada una de sus partes sean sencillas. La cuestión no es contraponer sencillez versus mantenibilidad, sino que ambos conceptos están íntimamente relacionados (y además su relación es proporcional).

¿Por qué nos debemos preocupar de que lo que desarrollamos pueda ser mantenido con relativa facilidad?, por la sencilla razón de que durante la vida de cualquier producto software, sea algo que se venda bajo licencia, un desarrollo interno en nuestra compañía o incluso cualquier proyecto personal, éste va a ser mantenido durante mucho más tiempo que el que ha costado desarrollarlo. Es más, cuanto más éxito tenga, más cambios y mejoras se nos van a pedir, por lo que el ritmo de evolución de un producto puede ser considerado también como un síntoma de su éxito.

Yo siempre pongo el mismo ejemplo: ¿compraríamos un coche que es casi imposible de reparar o al que es muy difícil cambiarle el aceite?.

¿Verdaderamente tenemos esto presente cuando escribimos líneas y líneas de código?.

Estos conceptos de sencillez y facilidad de mantenimiento son fáciles de entender, pero lo que no es tan fácil es tenerlos presentes en nuestro día a día: nadie es capaz de escribir código limpio a la primera, sino que para llegar a él debemos buscar esa solución sencilla mediante refactorings, repaso continuo de lo ya realizado, etc.

Un ingenuo desarrollador simplificará cuando le venga bien, no de manera sistemática, no se preocupará de que lo que hace pueda ser matenido / depurado con facilidad (no percibe que esto le puede golpear en el rostro con efecto boomerang); un programador cándido busca exclusivamente que lo que está haciendo funcione a cualquier precio, sin tener en cuenta eso de que pan para hoy y hambre para mañana...

Si nuestro software es mantenible, estaremos poniendo los cimientos del éxito del mismo. Si no lo es, nacerá moribundo y terminará convirtiéndose en un fracaso y fuente de clientes insatisfechos. Conseguimos este objetivo de mantenibilidad cuidando de que las partes individuales de nuestro producto sean sencillas.

Páginas

¿Por qué leer El Libro Negro del Programador?

Adquirir desde:
Amazon (kindle eBook / papel)
CreateSpace (papel)
PayHip (epub / mobi / pdf)

El libro negro del programador.com
Segunda Edición - 2017

El libro negro del programador.com
Now available in english!

Archivo

Trabajo en...

Mis novelas...