Desarrollo de software. Joel Spolsky. Programador aceptable, gran programador, diferencia, comunicación

Joel Spolsky es un conocido (sobre todo por el sitio web Stack Overflow, que fundó junto a Jeff Atwood) ingeniero de software, autor, emprendedor y divulgador, especializado en los campos de la programación y de la ingeniería del software.

Spolsky realiza una reflexión sobre un tema que he tratado recurrentemente en mis artículos y que es la comunicación como un elemento de gran valor e importancia tanto en los proyectos de desarrollo de software (traducción libre): «La diferencia entre un programador aceptable y un gran programador no se basa en el número de lenguajes de programación que dominan o si prefieren Python o Java, sino que se encuentra en la capacidad de comunicar sus ideas».

Esta cita, que sobre todo intenta poner en relieve la importancia de la comunicación, es extensible al resto de roles del proyecto.

Y es que acaso, ¿no es comunicación la codificación? No es lo mismo un código que se pueda leer, comprender y mantener con facilidad que otro en el que el programador no se haya aplicado en eso. ¿No es comunicación los comentarios en el código?, ¿no es comunicación la documentación técnica de un proyecto?, ¿no es comunicación la que tienes con los compañeros en el proyecto?, ¿no es comunicación la que puedes tener en un momento determinado con el cliente?, ¿con tus superiores?, ¿con personas de otros departamentos?.

Yo no resto importancia a la capacidad técnica de un desarrollador, antes al contrario, pero para poder destacar (salvo que estés al este de la campana de Gauss), esa cualidad debe venir acompañada por otras y la comunicación es una de ellas. De hecho muchas empresas, tienen muy en cuenta esa capacidad antes de contratar determinados tipos de perfiles.

Desarrollo de software. Gerald Marvin Weinberg. El valor de la experiencia

La experiencia es importante. En el desarrollo de software importantísima. Muchas de las ideas utópicas que teníamos sobre lo que era este negocio y muchos de los conocimientos adquiridos en nuestros estudios se estrellan cuando se pasa de la teoría a la práctica.

Experiencia no es acumular años en un determinado trabajo. La experiencia no es lineal, sino que realmente se va adquiriendo a través de los proyectos en los que estamos trabajando, de todo lo que pasa en los mismos y de las personas que conocemos y con las que colaboramos. La experiencia requiere aprender de los errores. La experiencia también requiere humildad.

Humildad para poder seguir aprendiendo de otros, para que puedan prestarte su ayuda, su opinión, sus conocimientos, sus propias experiencias.

Sobre este asunto Gerald Marvin Weinberg realiza la siguiente reflexión: «La experiencia no necesariamente enseña nada»

La experiencia cambia tu percepción del mundo, en este caso, de los proyectos de desarrollo de software, pero no necesariamente soluciona nada, no necesariamente tiene por qué tener las claves para que todo vaya bien. Ahí es donde hay que demostrar esa humildad, en saber que se ha evolucionado, que se ha alcanzado un conocimiento que está más allá de los libros, pero también en ser conscientes de que nuestra experiencia, nuestro conocimiento, está para servir al proyecto sin que se tenga por qué cerrar puertas a otros puntos de vistas, independientemente del rol y experiencia que tengan los mismos.

Desarrollo de software. Por escrito

Considero muy importante que las decisiones que se toman en un proyecto de desarrollo de software queden por escrito y que cuenten con la aprobación de las distintas partes afectadas por las mismas. De igual importancia que lo anterior es revisar todo lo que queda por escrito porque de igual forma que lo puedes utilizar en un futuro para exponer un determinado punto de vista también puede ser utilizado en contra tuya.

En muchas ocasiones a la hora de revisar acuerdos, las actas nos deparan sorpresas y si la hemos aprobado sin revisarla adecuadamente nos estamos arriesgando a encontrarnos posteriormente con ciertos matices que no reflejaron la realidad exacta de lo que se habló en su momento, lo cual puede traer consigo problemas al proyecto. No repasarse las actas es algo demasiado común, se considera algo prescindible, pero puedo asegurar que no lo es.

En desarrollos donde hay problemas entre cliente y proveedor la existencia de que los acuerdos queden por escrito resulta fundamental porque de lo contrario el débil estará siempre a expensas del más fuerte (también lo estará con la documentación por delante, pero por lo menos le permite jugar unas cartas que de otra manera no tendría a su disposición).

Sobre la autogestión

Creo en la autogestión en primer lugar porque lo entiendo como algo natural. Nosotros nos autogestionamos, tomamos decisiones, acertamos y nos equivocamos. Pedir a terceros que decidan o tomen decisiones por nosotros dentro es una opción personal, en ocasiones la más fácil, pero desde mi punto de vista no es el camino adecuado (hablo de decisiones personales, no de consejos y otras decisiones que se puedan delegar o contratar a terceros que son profesionales o especialistas en una materia).

Creo en la autogestión porque mi vida laboral se ha desarrollado en un entorno de estas características: estos son tus proyectos, estos tus recursos, gestiónalos. De esta forma cada proyecto era un mundo independiente formado por el equipo de proyecto y yo. En pocas ocasiones se han tenido que escalar decisiones o problemas hacia niveles superiores, tanto por parte del proveedor como mía. Y eso que la convivencia no ha sido siempre fácil pero todo se puede complicar todavía más cuando se pierde la confianza, cuando no se aborda un problema dentro del ámbito del proyecto.

No se debe confundir autogestión con anarquía, cuando ambos conceptos se unen, estamos ante una taifa no ante un equipo que forma parte de algo mayor. La autogestión se debe regir en base a unas normas generales de actuación por parte de la organización, por unas directrices que vendrán de otros órganos y personas.

La autogestión en los equipos se ha convertido en un concepto muy de moda, sobre todo por la expansión de las metodologías ágiles, donde se fomenta que los equipos de trabajo sean familias (unidas) dentro del ámbito profesional, sin embargo, tal y como he indicado al principio, la autogestión es inherente a nuestra propia existencia y tan antigua como el ser humano.