Número 13
25 de maio de 2022

O segundo 80%

Lembro un día no que nun dos meus proxectos acadei o “feature complete”: o punto no que hai código escrito para implementar toda a funcionalidade requirida no programa. É un fito moi importante: o máis gordo do proxecto xa está feito e só quedan os remates finais, corrixir erros, preparar o proxecto para produción e, finalmente, entregar o resultado final. Na xuntanza de informe de progreso anunciei con toda a satisfacción que o meu proxecto xa chegara ao 80%.

Ai si?

Hai un chiste que di que a enxeñería do software ten unha versión perversa do principio de Pareto: o primeiro 80% do proxecto consume o 80% do tempo asignado, e o 20% restante consume o outro 80% do tempo. Ese proxecto non foi unha excepción: o 20% restante comezou a demorarse máis e máis ata que, como dicía o chiste, levou tanto tempo como o 80% anterior.

Un filósofo grego vén de tirar unha frecha cun arco. A frecha está a metade de camiño; a distancia entre o arco e a frecha está marcada “80%” e a distancia entre a frecha e o obxectivo tamén está marcada “80%”.Unha recente teoría di que Zenón de Elea xestionaba proxectos de software cando formulou os seus famosos paradoxos sobre o movemento.

Esa non foi a primeira vez que eu cometera ese erro, a pesar de que xa sabía eu como funcionaban esas cousas. Incluso contara o chiste e todo! E agora que teño un boletín sobre enxeñería do software, pensei que sería unha boa idea escribir sobre por que este fito nos leva a este engano. Cunha pouca sorte, a próxima vez que nos vexamos nesta situación, nin eu nin os membros da miña prestixiosa e selectiva audiencia habemos cometer este erro.

Nun proxecto de software hai unha morea de tarefas por facer: analizar requirimentos, facer algo de deseño, algo de implementación, corrixir algúns erros, máis deseño e máis implementación, tirar algún código ao lixo e substituílo por outro mellor, preparar o ambiente de produción, facer probas “alfa”, corrixir erros, escribir os manuais, corrixir máis erros, facer probas “beta”, corrixir outros erros, configurar a monitorización, tirar máis código ao lixo porque non escala e substituílo por outro que si escala, corrixir erros, e finalmente entregar o proxecto.

Nesta lista de enriba, o “feature complete” queda xusto antes das probas “alfa”. Ao chegar a este punto, estamos tan satisfeitos pola análise e deseño e implementación que fixemos, que pensamos que xa temos case todo o traballo feito. Con todo, se mirades na lista, aínda queda un monte de cousas por facer e, mirándoas unha a unha, vese que ocupan moito tempo e esforzo. Por que, logo, pensamos que non?

Eu penso que é por tres razóns. A primeira é que somos uns optimistas consumados. Sempre facemos estimacións de tempo pensando que non imos cometer erros ou que non imos ter que desfacer e repetir partes do noso traballo. Calquera que teña traballado nun proxecto de software que dure máis de cinco minutos sabe que non é así.

O segundo motivo é que, na enxeñería do software, sobreestimamos a importancia da programación respecto das outras disciplinas. Nun proxecto de software non só programamos; escribimos documentación, administramos sistemas, configuramos, integramos, xestionamos proxectos, xestionamos erros, e xuntámonos con xente para poñernos todos de acordo. Cando chegamos ao noso “80%” e miramos o que nos queda por facer, vemos moita configuración, moita documentación, e moitas outras tarefas que non son programación, subestimámolas e pensamos que van levar moito menos tempo do que levan na realidade.

E a terceira razón é que a maioría dos proxectos acaban cancelados e, en consecuencia, todos temos comezado moitos máis proxectos dos que temos rematado. Polo tanto, temos moita máis experiencia coas partes que van antes do “feature complete” cás que van despois. Isto fai que, por unha banda, tendamos a subestimar as partes ás que non estamos tan afeitos e, pola outra banda, as fagamos máis lentamente que as partes que facemos adoito.

Se non queredes que se demoren tanto os vosos proxectos, aquí tedes as causas. Pola miña parte, vou tratar de apreciar mellor a importancia e custo das tarefas que non son de programación pura e dura, e vou usar proxectos simples para practicar as fases finais e ter máis práctica a próxima vez.

A ilustración desta Folla está baseada nunha xerra grega.