El deathmarch no deixa massa temps lliure, però l'actualització a la versió 6.10 d'Ubuntu tampoc n'ha necessitat gaire. Havia provat la Live i pareixia que tot anava bé, així que va ser cosa de deixar la màquina actualitzant i al vespre passar-me una estona contestant alguna que altra pregunta relativa a si volia conservar la configuració antiga o no. L'actualització ha anat molt fina, fins i tot ara funciona la impressora!  Encara no hi ha els drivers però al manco puc imprimir en color. L'scanner que sí anava ara no funciona, hi he de perdre un poc més de temps, però temps precisament és el que no em sobra. La feina va a bon ritme. He dit que n'és de bo l'equip? :) Segurament arribarem a temps per l'entrega. Encara hi ha força riscs, sobretot perquè part de la feina depèn d'un proveïdor extern, però són riscs controlats i s'han previst mesures per a minimitzar l'impacte d'un retràs en l'entrega de proveïdor. Ja sé que les comparacions són odioses, però la veritat és que no es pot comparar l'equip que hem format amb la gent que ens envien empreses externes. No ja per la formació que tenen, sinó per l'esperit. El meus gurús preferits, en Ricardo i en Joel Spolsky en parlen als seus respectius blogs. La passió per la feina, per la informàtica i la programació és mala de trobar i quan trobes un conjunt de gent que sí la té es nota. L'altra dia em va arribar que una a important empresa del sector dels viatges li era molt difícil trobar gent, bona gent. El problema que hi veig jo és que els departaments de recursos humans no estan preparats per cercar la passió en la feina, sovint no saben ni què demanen, i potser es descarta gent que podria ser molt valuosa per l'empresa. L'altra raó, i segurament tant o més important, és que la gent bona a més de passar gust fent feina  també li agrada poder mantenir la família. Ja no diguem poder contractar un grup de gent. Per una banda crec que les empreses no són conscients del que pot fer un grup de programadors eficients i quan ho són no són conscients del seu cost. Però bé, anant al tema de l'actualització, el Firefox 2.0 funciona i a més em funciona l'Eclipse 3.2 que ve amb l'Ubuntu. Per acabar-ho de rematar el plugin per Python també va d'allò més bé, així que pareix que després de tot podré aprofitar molt més el G5. No vull acabar l'apunt sense agrair a Juan (a.k.a. MorenoSan) això: Un conjunt d'aferratines de PostgreSQL en Japonés. M'ha fet molta gràcia! Ja ocupa un lloc destacat al suro, junt amb el cartell de les darreres jornades de Bulma i els dibuixos dels meus menuts.

M'agrada pensar que un projecte en que un no aprengui res no s'ho val. En el cas de projectes Death March sempre hi ha la temptació d'anar a cercar les solucions màgiques, sovint sense més argumentació que un "wishful thinking": posar n-mil programadors pel projecte, pensar que l'eina màgica-que-ho-fa-tot-menys-el-cafè ens permetrà acabar a temps, ... Particularment me'n faig enfora d'aquestes temptacions, però a la vegada m'agrada aprofitar cada projecte per a introduïr millores respecte als projectes anteriors. Si no pots aprendre de l'experiència passada mal anam, no? En aquest projecte hem aprofitat per introduïr dues tecnologies que ens solucionen dos problemes que teníem a molts projectes però que en aquest tenen una criticitat que fan que la solució sigui imprescindible. Per una part necessitàvem poder controlar en temps d'execució alguns paràmetres de l'aplicació: nivell de depuració, temps de la la memòria cau de segon nivell, ... Per una altra necessitam un mètode ràpid d'enterar-nos dels errors que es produeixen a l'aplicació sense tenir que anar al servidor de producció. El primer problema ho hem pogut resoldre gràcies a l'excel·lent support que té Spring per JMX. A més això ens permetrà dur una monitorització fina d'alguns paràmetres que ens interessen de l'aplicació mitjançant OpenNMS. Tot programari lliure! El segon problema ho hem resolt també gràcies al programari lliure. Concretament gràcies al Jabber i a una API per accedir-hi anomenada Smack. Quan ho ajuntam tot amb Spring podem fer la nostra pròpia implementació de la captura d'errors i fer que ens envïi un missatge amb el log de l'error quan aquest es produeix. L'usuari veurà una pantalla tota xul·la d'avís i la gent de programació rebrem l'avís complet i en temps real del que ha passat junt amb la traça del missatge. En el desenvolupament del projecte ens hem trobat també amb la necessitat d'ordenar i filtrar conjunts d'objectes. Java ens permet fer-ho, però la quantitat de filtres i operacions a fer feia que la perspectiva no fos massa agradable ni massa pràctica. No hi ha temps per a escriure i molt menys depurar tota la quantitat d'operacions que es necessiten fer damunt la llista d'objectes que tenim. Inicialment vàrem pensar en una base de dades lleugera, però totes eren molt més del que necessitàvem, i a més comportava tenir que fer transformacions damunt la nostra llista d'objectes. La solució va venir de la mà d'un projecte anomenat JoSQL. Aquesta llibreria ens permet tractar una llista d'objectes com si fos una base de dades sql. La funcionalitat que té és tot el que necessitàvem i més. Som conscients que estam canviant temps de desenvolupament per temps de procés i memòria, però precisamente el que tenim és molta CPU i poc temps per a entregar el projecte, així que la tria era molt clara. De totes maneres quan més ho pens més avantatges li veig a JoSQL, el codi de cerques i filtres damunt les llistes queda molt clar, reduït a una o dues setències SQL i per tant molt més bo de depurar i mantenir. Una vegada més estaríem guanyant un temps preciós que necessitarem en altres etapes del projecte. Aquest projecte també ens ha servit per provar una altra manera d'organitzar la feina. La gestió del risc s'ha de coordinar amb un tipus de desenvolupament que ens permeti avançar bé i aviat. Això implica paralelitzar tot el que es pugui i que tothom sàpiga el que ha de fer i perquè ho fa. La veritat és que n'estic molt de l'equip. Si tenim alguna possibilitat d'entregar aquest Death March Project a temps serà gràcies a que la gent que hi ha implicada és d'allò que en trobes pocs. Tot i això encara No es pot cantar victròria, encara hi ha un risc molt alt, aliè a l'equip de desenvolupament, que poc a poc està transformant aquesta missió impossible en un projecte ugly. És el que tenen aquests projectes, fins que no s'acaben un no pot fer recompte de baixes o cantar victòria.

La teoria de la finestra trencada data de 1995, i es pot trobar un bon resum aquesta referència. Bàsicamen ve a dir que la degradació d'un barri, d'una casa, d'un cotxe,.. comença per petites coses que se van acumulant fins que la degradació arriba a un punt on és ja difícil la recuperació.

La idea és atacar donçs les petites mostres de degradació abans de que es facin més grans. En una barriada procurar mantenir els carrers nets, recullir les escombreries, mantenir els jardins i els parcs. La idea és que quan una cosa està en bon estat, quan encara no s'ha començat a degradar, és molt més difícil donar el primer pas que un cop la degradació ja ha començat.

Si no hi ha escombreries al terra és menys probable que algú les hi deixi. Si ja n'hi ha, el més probable és que n'hi acabi haguent més. Tanmateix ja n'hi ha una, un parell, un munt, fins que tot és bassura.

Passa el mateix amb els cotxes avariats. Poden passar dies a la carretera o al carrer sense que passi res, però una vegada s'ha trencat el primer vidre la degradació és molt ràpida, en un parell de dies ja no hi haurà rodes, peces interiors, etc.

Aquesta teoria també és aplicable al mon del programari. Quan es té un programa ben estructurat, definit, amb un estil de programació clar és molt més probable que la persona que ho tengui que mantenir ho faci seguint el mateix estil. Al contrari, si ja des de l'inici el nostre codi és descuidat, sense comentaris ni estructura, el més probable és que la cosa vagi a pitjor. Tanmateix, es pot pensar, no vindrà d'aquí. D'aquí que en la posterior evolució del programa ens poguem trobar amb un conjunt de pegats mal fets, codi que no té sentit, una arquitectura inexistent... L'efecte de la finestra trencada fa que una vegada que ha començat la degradació sigui molt més probable que aquesta continui.

Sovint, però, en el món del programari, no queda més remei fer pegats ràpids per corregir un error de funcionalitat de seguretat o del que sigui. No hi ha cap mal amb això, sempre que tenguem en compte que ha de ser l'excepció i no la regla. La idea és que una vegada s'ha solucionada la crisi, s'ha de dedicar temps a fer les coses bé. En cas contrari ens trobarem amb la primera finestra trencada, i és molt més probable que el nostre programa evolucioni cap a un engendre mal de mantenir.

Fitxem-nos però que l'evitar l'efecte finestra trencada no vol dir que tenguem que passar-nos la vida perfeccionant un programa fins a deixar-ho perfecte. La perfecció malhauradament en programació no existeix: sempre podríem fer el codi millor, més ràpid, sempre podríem posar més funcionalitats, fer que el programa fes el que volem de la manera més òptima. No hem de perdre el concepte de "prou bo", és a dir, hem de saber també quan aturar.

Si seguim amb l'exemple de la barriada, vol dir que no fa falta que al barri totes les cases siguin palaus. Sovint basta que siguin vivendes dignes, amb les façanes pintades i els interior cuidats. Cases que tenen un cost que la gent es pot permetre i fetes de tal manera que el cost de manteniment també sigui baix.

Una vegada hem conseguit que el nostre programa sigui prou bo, es tracta de mantenir-ho així, d'evitar ser el primer en trencar la finestra i que si algú altra la trenca, arreglar-ho i posar el vidre el més aviat possible, ja que si no és així, acabarem amb l'equivalent en programari a una casa apuntalada i que amenaça caure.

En una entrada anterior parlava dels projectes Death March i de la classificació que en fa n'Edward Yourdon al seu llibre Death March. Ara escric això alegrant-me d'haver comprat i llegit el llibre: estam enbarcats en un death march project.

Quan un s'embarca en un projecte d'aquests, el primer que ha de saber és en quin tipus de projecte s'està embarcant i quina és la companyia. Jo aquest, i segons la classificació de Yourdon, ho classificaria com un projecte de "Missió impossible", és a dir, es compta amb un equip altament motivat i capaç, però els riscs que poden fer fracassar el projecte són motls i variats.

Si als projectes normals ja s'ha de dur molta cura amb la gestió, als death march encara és molt més crític. Es pot pensar que en un projecte on les premures de temps són important no s'hauria de dedicar temps a la planificació, control d'errors, de versions, al la comunicació, res més allunyat de la realitat. Les estratègies de "codifica com un boig" [1], potser estan bé per fer veure ques es fa molta feina, el problema però, es que sovint aquesta feina és poc productiva i no garanteix que el projecte arribi a bon port.

La planificació i el control en aquests tipus de projectes és doncs tant important o més que en els projectes "més tranquilets", el que potser haurem de fer és no entrar a tant nivell de detall en alguns aspectes, si està un 80% bé ja és suficient, el 20% restant, que marcaria l'excel·lència en un altre projecte, és massa costós en termes de temps i cal evitar-ho si volem tenir èxit. Per exemple, tant fa si l'anàlisi de casos d'ús està fet amb la darrera eina de disseny UML, amb tots els colorins del món i enquadernat a tapa dura, potser amb un troç de paper que exmplique el que es vol fer és suficient. La cosa és que hi ha d'haver aquest troç de paper i hi ha d'haver una estratègia de feina orientada no a fer moltes hores i molta feina, sinó a fer feina efectiva.

Tanmateix, algunes vegades ni tota l'estratègia i planificació del món salvarà el projecte, senzillament està condemnat al fracàs: el temps és massa curt, el recursos insuficients, el que s'ha de fer no està clar, els riscs del projectes són massa o qualsevol combinació de les anteriors. El problema és que normalment un no sap que passaran coses d'aquestes fins que ja ha començat el projecte. Davant això, la planificació i la comunicació són importants. No serveix de res dir allò de "està al 90% acabat" quan sabem positivament que el 10% restant és el bessó del projecte. Val més ser realistes i dir les coses clares. Tanmateix si la continuïtat de la feina depén de l'èxit del projecte i aquest no té cap possibilitat d'acabar bé, al manco n'haurem informat a temps i es podrà, si es vol, reaccionar.

Quan un projecte s'ha de fer en un temps molt curt, per mi, el més important és disposar d'un bon equip de gent. I per "bon equip" no vull dir un equip gran de gent, sinó un equip de gent molt qualificada, acostumada a fer feina plenada i molt motivada. Això i moltes hores extres, clar. El problema és que un ritme de 10 o 12 hores diàries, difícilment es pot mantenir durant més que un parell de mesos, així que a partir d'una certa durada del projecte convé començar a fer comptes i veure si posar més gent al projecte compensa el retràssos que implica tenir que formar al personal nou i la complexitat adicional de comunicació que hi ha quan l'equip de feina es fa més gran

Per projectes de curta durada, entre un i tres mesos, és molt més eficient un equip petit, tirant d'hores extres fetes amb seny, que un equip amb el doble de gent. La durada del projecte sovint marca també el nombre de tasques que s'han de fer i el grau de paralel·lització que es difícil que arribir a ser l'òptim [2]. A vegades es pot aconseguir que el projecte faci més via si malbaratam recursos, és a dir, si tenim gent sense fer res, esperant a que li toqui fer el seu trocet. Sigui com sigui, ens duu sempre al mateix, s'ha de planificar, s'ha de saber l'abast del projecte i s'ha de dissenyar una estratègia amb probabilitats d'èxit. D'altra manera no sabríem mai si amb més recursos s'hagués pogut arribar a temps o al contrari, si s'hagués tingut que tirar de treball extra per acabar el projecte

Tornant al nostre projecte, crec que serà complicat, els riscs són grans, però l'equip és molt bó. Les meves estimacions diuen que en condicions normals podem doblar o triplicar la productivitat estandard. Tot aquest optimisme sempre cal estar atents als riscs, al seu control i a la seva minimització. Controlar els riscs és costós, s'hi han de dedicar temps i recursos, però no fer-ho pot suposar que un projecte de "Missió impossible" es convertesqui en un projecte suicida. Yourdon diu que les estadístiques estan al nostre favor [4], i si Yourdon ho diu ho haurem de creure.

Ja sent la musiqueta: tan-tan-tan-tan-tant-ta ta ta ta, tiruriii [3]

---

[1] Code like hell
[2] Quin mal que han fet aquí les eines com M$Project que suposen que qualsevol recurs és intercanviable!
[3] La música mai ha estat e meu fort. Deduïu el nom de la cançò pel context. I no, no hi ha premi pel qui ho adivini. :)
[4] Els death march projects que tenen més probabilitat d'èxit són aquells on el projecte és de curta durada i l'equip és petit i està molt motivat. En aquests tipus de projectes és molt més bo de fer que la gent pugui "aparcar la seva vida" durant el temps de durada del projecte. En projectes amb molta gent o de durada molt més gran, hi ha tan dificultats per a que tothom "doni el call", pels motius que siguin o que pugui deixar-ho tot durant tant de temps (el més normal). Això per no parlar de l'esgotament físic i mental o de que en casos així molts dels integrants del projete s'estima que deixaran l'empresa dins el proper any, amb la qual cosa l'empresa es pot trobar amb un projecte fracassat i amb el capital humà perdut.