Quizá, por la cultura que nos rodea, hay peligrosas, Oscuras, maneras de entender la profesión… que no van a cambiar

Hace ya muchos años de mi primer trabajo de programador (antes de tirar líneas en Java), y fue con Clipper (lenguaje que la mayoría ni conoceréis). Ya por entonces, el «encargado» estaba preocupado por cuantas líneas de código programaba, como si eso fuera una medida de  productividad.

En 2021, aun hay quien piensa que existe manera de medir la productividad de un programador e, incluso, hacerlo con líneas de código.

.

.

Hace pocas semanas, estaba con Mss Nobody en el enésimo intento de intentar explicar porque separar Testing de Desarrollo, creando dos silos, genera cantidad de desperdicio, conflictos, objetivos no encaminados a la entrega de valor. 

Los primeros trabajos de Peopleware, años 80 y antes, ya hablaban de ello. 40 años después aún siguen ahí.

.

.

Esta semana, me tocaba ayudar a otra Mss Nobody con el eterno problema de que su cliente, y su jefe comercial, generan proyectos con «planificaciones demasiado optimistas», «expectativas no realistas (pedir algo imposible)», generando «excesiva multitarea (estar en muchas cosas a la vez)» y fomentando «saltarse mínimos de calidad» para hacer entregas.

En el año 96, McConnell ya publicó un estudio estadístico (va post de 2010) sobre los errores más frecuentes y desastrosos en proyectos software, los que te he mencionado antes ocupaban, y seguramente HOY ocupen, las 4 primeras posiciones.

.

.

Este diciembre de 2021, he tenido que volver a debatir sobre porque comparar el desarrollo software con la albañilería no tiene sentido y es MUY peligroso. 

¿Por qué esa insistencia casi centenaria en hacerlo? ¿Por qué no comparar el mundo del desarrollo software con la investigación científica donde fechas y resultados tampoco están claros, es un sector crítico, y de alto conocimiento en ciencia tecnología? De verdad, no lo sé.

Pero el debate de por qué no gestionamos proyectos como los albañiles sigue ahí, tristemente.

Llevo escribiendo sobre esto desde 2011 (dos razones por las que desarrollar software no es lo mismo que fabricar coches o construir casas, el ejemplo del albañil y la estimación software y la ágil o ya, pero al final… mi cliente quiere tiempo y presupuesto). Otros más adelantados, como Fowler, ya lo hicieron en 2005.

.

Siempre digo, sabemos, que los cambios culturales son lentos, que los avances en tecnología van mucho más rápidos que los cambios en modelos de gestión.

Pero, quizá ciertas cosas no van a cambiar en nuestra cultura, porque quizá es que son nuestra cultura.

.

.

Por cierto, el viernes tenemos el último «Preguntas Ágiles, fast and furious» en INSTAGRAM del año, en abierto, para acercar a TODO EL MUNDO la cultura Ágil (no Oscura), los equipos Ágiles, etc., y vamos también, antes de que termine el año, con otra iniciativa en abierto que repite: EL ÚLTIMO CURSO GRATIS, ONLINE y en DIRECTO que daré (el cuarto curso en abierto que doy este año), LA INFO PARA INSCRIBIRSE AQUÍ.

 

Javier Garzás

2 comentarios en “Quizá, por la cultura que nos rodea, hay peligrosas, Oscuras, maneras de entender la profesión… que no van a cambiar”

  1. Saludos Javier desde Caracas, Venezuela. Me ha gustado mucho este post porque me hace recordar gran numero de Miss Nobody que he conocido y que conozco actualmente, pero creo que el problema puede venir de la creencia de que al cliente se e debe dar todo lo que pida, sin medir el esfuerzo y carga laboral del equipo de trabajo.

    Como nota graciosa te puedo decir que conoci clipper summer 87, pero antes ya conocia dBase II, dBase III corriendo en una PC con sistema operativo CP/M. Todo esto sin contar la tarjeta perforada. jejeje.

    Saludos, Feliz Navidad y exitos en el 2022.

Deja un comentario

Tu dirección de correo electrónico no será publicada. Los campos obligatorios están marcados con *

Ir arriba