Lista de capítulos El Libro Negro del Programador

En este capítulo se hace una presentación general del libro.

El Libro Negro del Programador pretende mostrar todas aquellas circunstancias que rodean el desarrollo de software y que determinan su éxito o fracaso.

Un desarrollador profesional debe incorporar unos hábitos de trabajo que le haga avanzar en su trabajo generando un código limpio y de calidad; para ello a medida que se avanza en el código de producción hay que respaldarlo con pruebas (o comenzar precisamente por ellas) y realizar una actividad de mejora y simplificación constante y continua. Se escribe código, se prueba, se refactoriza y simplifica y vuelta a empezar.

En este capítulo se explica cómo la deuda de no desarrollar de ese modo es demasiado alta.

Ingenuamente se cree que el éxito de un proyecto software consiste básicamente en entregar lo acordado a tiempo; nada más lejos de la realidad.

Hay factores que indican en qué medida el proyecto ha sido un éxito o no: estos condicionates saltan a la luz tiempo después de haber entregado el proyecto. Un gran número de estos fracasan tiempo después de su entrega, en el momento en que se solicitan cambios, se deben corregir errores no detectados o hay que evolucionar la solución.

Un profesional detecta estos factores desde el inicio del proyecto y los intenta corregir en la medida de lo posible. Es sorprendente porque son más cuestiones de equipo, actitud y honestidad que aspectos técnicos.

En este capítulo reflexionamos acerca de la necesidad de pensar a solucionar problemas software a partir de ciertos principios de diseño y buenos hábitos de programación que van a hacer nuestro código mucho más legible y mantenible.

Asumimos con demasiada frecuencia que nos vamos a acordar a la perfección de lo que desarrollamos hoy, cuando en realidad debemos ser autores que escribimos para los demás; debemos mostrar claramente la intención de diseño en nuestro trabajo así como aplicar sencillos hábitos que muy fácilmente mejorará la calidad de nuestro trabajo.

¿Os habéis encontrado alguna vez con la típica aplicación que sólo la entiende... el que la hizo?. A mí me ha pasado que he identificado claramente quién ha hecho un trabajo leyendo su código: en este vamos dejando una impronta que puede ser mala, malísima o de excelente calidad.

Sostengo que en la medida en que rellenamos una hoja en blanco con líneas de código que resuelven algo, somos autores cuya misión es hacer un software funcional que pueda ser entendido y asumido por los demás.

El error de concepto es que nos enseñan a programar para nosotros mismos, no para que otros entiendan nuestro trabajo. ¿De qué sirve un flamante rascacielos si luego no puede venir el equipo de mantenimiento a cambiarle una bombilla?

Un programador profesional hace su trabajo con la mente puesta en que otros lo puedan entender.

Con muy poco esfuerzo podemos asumir buenos hábitos que harán que podamos crear un software más limpio y legible, aumentando así la rentabilidad de nuestro trabajo.

Usamos en nuestros desarrollos multitud de librerías, componentes externos y APIs de terceros que evolucionan cada una a su propio ritmo. Al igual que es bueno y deseable que nuestro software evolucione, ¿somos conscientes de que todos esos componentes externos pueden evolucionar igualmente y, por tanto, crear una dependencia letal en nuestra solución?.

En este nuevo capítulo reflexionamos acerca de cómo seleccionamos esas librerías externas y el delicado equilibrio que debemos considerar cuando usamos un componente externo en nuestra aplicación.

El software es una construcción jerárquica: creamos código sobre piezas de software desarrolladas por otros, por tanto en cierta medida nuestras soluciones serán mejores o peores según cómo elijamos aquellas librerías sobre las que nos apoyamos.

A medida que una aplicación software va evolucionando cuando se incorporan nuevas características (previstas o no), la calidad del su código va deteriorándose. Esto es lo que ocurre de manera natural a no ser que trabajemos activamente para limitar este deterioro. Cuantos más cambios, más posibilidades de ensuciar el diseño, la estructura, etc.

La peor consecuencia que se deriva de esta situación es que se tenga que dedicar más esfuerzo al mantenimiento (cuando no es imposible) que verdaderamente a incorporar nueva funcionalidad. Cuando el esfuerzo de mantener un software es muy alto, posiblemente estemos ante clientes insatisfechos o bien estamos perdiendo oportunidades de explorar e invertir en otro tipo de productos. La inmantenibilidad de un proyecto lo conducirá al cementerio tarde o temprano.

Uno de los elementos que impiden el mantener siempre una solución limpia es la inercia o prejuicio a eliminar o cambiar en profundidad código previo: es un factor más, pero no menos importante.

En este capítulo vemos por qué ocurre esto y evidenciamos que en realidad al destruir de la manera correcta estamos ganando velocidad y productividad en los futuros desarrollos.

Uno de los males más perniciosos para nuestra profesión cuando se ha acumulado demasiado trabajo y las fechas en que debe estar terminado se acercan, es intentar añadir nuevos desarrolladores justo en esos momentos de crisis. Esta idea encierra en realidad la concepción de que al software es un trabajo mecánico: si dos producen veinte tornillos, cuatro necesariamente producirán cuarenta...

Debemos siempre plantearnos las mejores condiciones de trabajo como objetivo aunque no siempre se puedan conseguir del todo; de este modo, lo ideal para un proyecto es que lo inicie y lo termine el mismo equipo de trabajo. El añadir más desarrolladores al final, justo en momentos de tensión, horas extra y nervios a flor de piel, va a empeorar necesariamente la situación.

Todavía rechinan en mis oídos la pregunta ¿cuántos desarrolladores más necesitas?.

Muchos proyectos software fracasan no por la falta de pericia o habilidad de los desarrolladores, tampoco lo hacen por la falta de talento y la buena voluntad de sacar el proyecto adelante. En ocasiones, el actor que provoca que un proyecto termine en desastre es el mismo gestor, responsable, manager o coordinador.

¿Puede gestionar un equipo de programadores alguien que apenas conoce la naturaleza de un producto software?. ¿Se puede organizar un equipo sin conocer los detalles de la metodología que se usa sea cual sea ésta?.

He contado con experiencias horrorosas de malos gestores que literalmente se han cargado los proyectos en los que trabajaban, haciendo insoportable el trabajo del equipo. También he conocido muy buenos coordinadores que entendiendo la naturaleza del trabajo a realizar han tomado las decisiones correctas.

En este capítulo analizamos el importante papel de un responsable de equipo para que un producto software camine hacie el éxito.

En contra de los que muchos creen, gestionar no es mandar o dar órdenes para que estas se cumplan mágicamente, sino organizar, planificar y crear las condiciones necesarias para que el equipo de desarrolladores haga bien su trabajo. En este sentido, el responsable de un proyecto está al servicio del equipo y no al revés.

¿Cómo afrontamos una nueva fase del trabajo de un proyecto?. En este nuevo capítulo indicamos cómo solemos postergar justo hacia el final aquellas tareas que nos resultan menos interesantes, insidiosas o complejas. Cuando se acercan las fechas de entrega es precisamente cuando acumulamos más presión y estrés por llegar a tiempo y, por tanto, corremos más y vamos haciendo un trabajo de peor calidad que nos pasará factura más adelante.

De igual modo, un buen desarrollador siempre tiene la mirada puesta en lo que se ha hecho anteriormente, buscando mejoras, simplificaciones y un mejor diseño que permita avanzar en la solución aún más rápida y eficientemente. Esta mirada hacia atrás debe convertirse en un hábito continuo, pero debe realizarse a pequeños pasos.

En este capítulo abordamos estos temas. ¿Cómo debe ser el día a día ideal de un desarrollador profesional de software?.

A diferencia de lo que muchos creen, trabajar con productividad y eficiencia no consiste en pegarse a la silla diez horas seguidas día tras día; nuestra mente sólo resiste una actividad realmente creativa durante pocas horas, no más. Para desarrollar un buen software es mucho mejor avanzar con una constancia diaria que nos permita terminar las tareas de diseño e implementación con orden y eficacia.

En El Libro Negro del Programador no vemos únicamente qué es lo que tenemos que hacer para conseguir éxito como desarrolladores de software, que un proyecto salga adelante o cómo afrontar el día a día para que realmente seamos productivos. El punto de mira lo ponemos especialmente en aquello que solemos hacer mal (y a veces rematadamente mal) durante el desarrollo de nuestra profesión. Un programador profesional está lejos de ser exclusivamente alguien con un dominio y control total de ciertas tecnologías..., esto es un mirada muy estrecha sobre nuestro trabajo: hacen falta muchas otras cualidades creativas y productivas.

En esta ocasión, vemos cómo cualquier software caminará hacia el éxito si equilibramos correctamente tres factores: el suficiente talento, el necesario dominio de la tecnología que se emplee y la correcta aplicación de una metodología o disciplina. En muchas ocasiones un proyecto software fracasa porque alguno o varios de estos tres factores fallan. Esta es una regla elemental que casi siempre está presente.

De nada vale dominar completamente una tecnología si no la sabemos aplicar en el contexto de un proyecto con la suficiente metodología (que viene a ser como el marco de trabajo en el que hacer las cosas ordenadamente), o bien ser muy estrictos en esta última mientras se nos hace muy difícil resolver los problemas software que presenta el proyecto.

El éxito siempre se presenta cuando el talento, el dominio de la tecnología y la aplicación de una metodología están suficientemente equilibrados: los tres a la vez. Aunque siempre habrá excepciones, cuando estos tres factores se encuentran tenemos lo necesario para completar un trabajo o proyecto con la calidad profesional que esperamos.Sin el talento necesario, no sabremos resolver problemas con las herramientas de que disponemos; sin el dominio suficiente de la tecnología a usar, no podremos resolver ningún problema adecuadamente; sin una metodología que nos haga avanzar nos seguridad y orden, de nada vale lo anterior.

Hablar de un arquitecto de software es hablar de alguien con mucha experiencia, que controla muchos tipos de arquitectura y tecnologías, que sabe siempre tomar muy buenas decisiones de diseño cuando se comienza un proyecto, pero... ¿realmente nos encontramos con perfiles así en el día a día de los proyectos?. ¿Qué sentido tiene este rol cuando enfocamos el desarrollo de software desde un punto de vista ágil?.

En este capítulo sostengo que en la mayoría de proyectos no es necesario un rol de arquitecto, de alguien dedicado a esto al 100% y que además su presencia puede ser más un obstáculo que una ventaja.

Digamos que en proyectos realmente grandes sí es necesario establecer un marco de trabajo sobre todo cuando hay muchos agentes implicados, pero en cada una de las partes o en proyectos más pequeños, plantear una arquitectura al inicio es un tremendo error (cuando seguramente aún desconocemos todos los requisitos o con toda probabilidad estos van a cambiar). La mejor arquitectura o diseño a más alto nivel del sistema sólo se conoce en el camino de su implementación, a no ser que realmente se reúnan los requisitos que debe cumplir un auténtico arquitecto de software que se describen en el capítulo.

¿Podríamos construir un rascacielos sin un orden claro establecido previamente?. El software se asemeja en ocasiones a la construcción de un edificio en el que para avanzar bien, hay que hacerlo con orden, coordinación y disciplina.

Por lo general somo reacios a implantar una metodología correcta, sea cual sea esta ajustada a la naturaleza del proyecto, ignorando que así reducimos la rentabilidad metodológica de nuestro software en forma de menos errores, menores tiempos de mantenimiento, clientes más satisfechos, etc. Como desarrolladores profesionales debemos exigir a nuestros responsables la implantación de una metodología (y las herramientas necesarias para ello) y del mismo modo es responsabilidad del gestor del proyecto asegurar su seguimiento.

La causa subyacente y última por la que muchos proyectos fallan es precisamente la ausencia de una metodología: esta forma parte intrínseca de cualquier proyecto software.

Cuando se va a valorar nuestro software, siempre nos enfrentamente al problema de su naturaleza intangible: a muy pocos clientes les interesa saber la complejidad de diseño, lo bien que está estructurada una base de datos o la maravillosa gestión de la configuración que hemos puesto en marcha. Lo que realmente aprecia es el valor que le aporta e interfaces de usuario con buen e intuitivo diseño (y no precisamente en ese mismo orden); esto ocurre al manos en muchas ocasiones.

Un buen producto puede terminar en la basura sencillamente por no parecerlo. Cometemos muchas veces el error de no centrarnos demasiado en aquello que realmente un cliente o usuario final puede y va a valorar. Podemos tener el corazón del sistema cristalino y con el mejor diseño que si no se muestra en una interfaz de usuario mínimamente atractiva el cliente dudará y pondrá en cuestión el valor (y seguramente el precio) de lo que hacemos.

Uno de nuestros mayores vicios como desarrolladores de software es la afición (y adicción) por conocer muy por encima un enorme batiburrillo de tecnologías pero sin profundizar apenas en ninguna. Esto no está mal, en mi opinión, es más, hasta cierto punto es algo necesario para nuestra profesión: conocer últimas tendencias, tecnologías de moda, nuevos frameworks, etc. siempre va a aportar valor a lo que hacemos en el día a día. Nada mejor que conocer lo que hacen otros y la manera en que otros resuelven problemas.

Sin embargo, no es raro encontrar quienes pasan más tiempo husmeando por aquí y por allá que en resolver verdaderamente problemas o profundizando en una tecnología en particular. Esto se podría entender siempre y cuando no quisieras curtirte una carrera como profesional del desarrollo de software. El gusto y afición por saber es algo encomiable y necesario, pero sin olvidar que realmente entendemos y usamos correctamente una tecnología cuando nos embarcamos en proyectos con ella.

En este sector en donde las noticias, paradigmas de trabajo y novedades se suceden rápidamente, es fácil caer en la tentación de querer alardear de estar más al día que los demás; con este juego infantil, a lo mejor quedamos muy bien en conversaciones de cafetería (aunque seguramente aburramos a más de uno), pero cuando hablamos de desarrollar nuestra profesión, este conocimiento superficial apenas nos va a valer. Quien te contrata, por lo general, lo que quiere es ver qué trabajos has realizado (qué problemas has solucionado).

Cuando indicamos un trabajo realizado como parte de nuestro currículum, estamos diciendo mucho más que los detalles de ese proyecto: decimos implícitamente que hay software nuestro actualmente en producción, que conocemos ese universo en el que se enmarca con la suficiente profundidad, etc.

"Desarrollador experto de javascript", podemos leer en muchos currículums, pero ¿cuántos desarrolladores expertos pueden haber de js?

Si bien necesitamos conocer el mercado en el que nos movemos, necesidades de clientes, oportunidades de negocio, tendencias, etc. e igualmente necesitamos conocer qué tecnologías existen para resolver y dar respuesta a esas necesidades, si queremos tener más oportunidades de éxito, entonces no nos podemos quedar en el simple alardeo de conocer un poco de casi todo pero nada en profundidad: se nos olvida entonces que los desarrolladores de software vivimos para resolver los problemas de otros, no para jugar y flirtear obsesivamente con todo lo que va saliendo sin llegar a usar nada de todo eso para hacer algo útil. Cada uno elije su camino, pero en mi opinión un profesional se centra antes en conocer qué tiene que resolver, después busca las herramientas y tecnologías más adecuadas.

Un profesional se presenta con un extenso catálogo de productos y trabajos realizados y no únicamente con una enorme e interminable lista de tecnologías que conoce sucintamente.

Hay muchísimos factores que no tienen nada que ver con el software pero que determinan la calidad del desarrollo que realizamos. Existe cierta cultura laboral según la cual no está del todo mal visto echar más y más horas en el trabajo, lo que vulgarmente se viene llamando "calentar silla". Es más, en algunas empresas hasta se promociona. Sin embargo, cuando las horas extras se convierten en una necesidad crónica y la forma de trabajo, estamos seguramente ante un problema de falta de productividad.

No podemos aguantar jornadas laborales eternas día tras día sin que el resultado de nuestro trabajo se resienta. Esto es una ley inquebrantable.

Un buen profesional debe buscar siempre trabajar con productividad.

Dividir en partes más simples un problema complejo es una de las habilidades imprescindibles de un desarrollador de software. Cuando hacemos esto en la funcionalidad de cualquier aplicación empezamos a encontrarnos con que cierta problemática se repite en multitud de proyectos: encontramos un patrón común y el punto de partida para el uso de librerías y frameworks.

En ocasiones la pereza del programador invita a sentirse más cómodo reinventando la rueda que buscando librerías que ya resuelven esa parte específica de un sistema, seguramente por gente más experta y de mayor experiencia que altruistamente comparte su trabajo con la comunidad, o sencillamente nos creemos más inteligentes y nos lanzamos a hacer lo que ya está más que resuelto por otros, perdiendo un tiempo precioso en trabajo de fontanería en lugar de centrarnos en lo que aporta más valor al proyecto.

Por otro lado, conseguir aplicaciones desacopladas tiene también mucho que ver con la reutilización de partes funcionales mediantes librería y frameworks. Nuestra proyecto será de mejor calidad cuanto más desacopladas estén sus partes.

¿Desacopla-qué?, ¿por qué nos cuesta entender que debemos huir lo más posible de soluciones rígidas? En este sentido el (des)acoplamiento no tiene nada que ver con algún instinto animal de bajo nivel...

En este capítulo vemos cómo se relacionan los conceptos de desacoplamiento con el uso en mayor o menor medida de librerías y frameworks y por qué en ocasiones tenemos la tentación de reinventar la rueda...

Desarrollar software o programar es, en la mayor parte del tiempo que nos dedicamos a ello, depurar y corregir errores. En cierta medida, aprendemos a programar corrigiendo y resolviendo bugs y pequeños fixes.<

Sin embargo, este aspecto tan relevante de la creación de software no lo tenemos tan en cuenta cuando estamos trabajando en el diseño o escribiendo código útil o de producción.

Me atrevo a afirmar que la calidad de cualquier software está relacionada con su facilidad de depuración, que no es más que otro aspecto de la mantenibilidad del mismo.

No existe solución elegante si no es depurable, así de sencillo. ¿Compraríamos un coche que es imposible reparar ante cualquier avería? Aquí está una de las claves del software de calidad, la facilidad de depuración (aspecto que no siempre es suficientemente cuidado por los desarrolladores).

Sucede a menudo que casi sin darnos cuenta o bien intencionadamente, somos los únicos que controlamos un software específico en la compañía para la que trabajamos, bien porque lo hemos hecho nosotros mismos o bien porque nos hemos especializado en él. En esos casos es demasiado tentador pensar que la compañía depende de ti en cierta medida y concluimos así que eso nos dará mayor garantía laboral.

Nada más lejos de la realidad. Si forzamos este comportamiento nos estamos perjudicando enormemente como desarrolladores de software: la seguridad sólo la da la confianza necesaria en saber que tendremos éxito en proyectos heterogéneos, que aprenderemos lo que haga falta y que tenemos la suficiente solvencia técnica para salir adelante. Es más una cuestión de autoestima.

Me he encontrado con quienes defendían su especial parcela de poder en la solución en la que trabajaban, impidiendo a otros acceder a la información, compitiendo con cosas como 'esto es mío así que no me lo toques' e ingenuidades de ese tipo; nada peor para el progreso de un buen profesional.

Este es quizá uno de los capítulos más introspectivos de El Libro Negro del Programador, pero precisamente de eso trata el libro, de reconocer los errores que con más frecuencia cometemos los desarrolladores de software y que nos impiden progresar y hacer trabajos de calidad.

Los desarrolladores de software no aprendemos exclusivamente leyendo manuales y libros sobre nuevas tecnologías; para mejorar en la calidad de nuestro trabajo es fundamental leer y analizar los proyectos que otros desarrolladores con más experiencia han realizado y publicado.

Es frecuente encontrar un perfil de desarrollador que yo llamo "perezoso": aquel que no sale nunca del proyecto en el que trabaja y que fuera de él apenas sabe por dónde comenzar uno nuevo.

Como desarrolladores, debemos tener claro que una de las mejores fuentes de conocimiento es el trabajo de los demás.

¿Cuánto tiempo pierde un desarrollador de software en resolver errores relacionados con la mala gestión del sistema de control de versiones? ¿Cuántas veces nos encontramos atascados en resolver conflictos de compilación?, ¿o en arreglar pruebas que dejaron de pasar hace mucho tiempo? ¿Cómo podemos trabajar ordenadamente en varias versiones del mismo producto?

Es sorprendente lo poco productivo que podemos llegar a ser por no plantear correctamete una estrategia (aunque sea simple) de gestión de la configuración y por no poner en marcha (en uno o dos días) la infraestructura necesaria para implantar integración continua cuando el equipo lo forman dos o más personas.

No se trata de trabajar cuantas más horas programando mejor, sino de hacerlo de manera eficiente: ¿todavía no hemos aprendido que para desarrollar software de calidad hay que abonar el terreno que lo rodea?

Los desarrolladores novatos no le prestan atención suficiente al correcto seguimiento de una gestión de la configuración y en la mayoría de equipos de trabajo se ve la integración continua como un capricho sin percibir la velocidad y rendimiento que ganamos con su implantación.

Igualmente, las empresas novatas no se dan cuenta del enorme coste extra que supone trabajar sin estas dos herramientas básicas que acompañan a la creación de productos software de calidad.

Hay una máxima que indica que las personas que más éxito tienen se dedican al 80% a lo importante y relevante, lo que aporta valor, y el 20% restante al resto: las personas improducivas hacen justo lo contrario. El establecer algunas normas básicas en cuanto a la gestión de la configuración e implantar en algún grado integración continua en nuestros proyectos hará que podamos acercarnos a ese 80% de la gente altamente productiva.

Los desarrolladores de software, en plena era digital y del conocimiento, tenemos más oportunidades que nunca para emprender. Desde tu propio ordenador, en tu habitación, en el salón de tu casa, sentado en una cafetería, podemos poner en marcha negocios que hasta hace bien poco tenían una barrera de entrada alta, aparte de que ahora existen muchas más tipos de actividades que pueden generar ingresos. Tendrás que decidir si alquilar tu mente a otros trabajando en una compañía o crear tu propio negocio. Nunca ha sido tan fácil, pero como todo, hay que aprender nuevas habilidades e incorporar materias de otros campos que no tienen nada que ver con la programación.

En este capítulo se enumeran todos y cada uno de los puntos relevantes para que un desarrollador de software trabaje con eficiencia. Sorprendentemente, de seguirlos todos o su mayoría, comenzarás a notar que dispones de más tiempo y que el trabajo que antes era pesado y monótono, ahora se realiza de un modo más fluido.