A més de llegir el llibre de Gabriel Ginebra als vespres, aquests darrers dies han estat prou interessant. Tant que m'agradaria compartir amb la gent que llegeix aquest blog un parell d'històries i reflexions que m'han passat aquests darrers dies. El títol del l'apunt potser no és del tot exacte, però no sé com anomenar aquest calaix de sastre. És en aquests casos on es veu perfectament el concepte de blog personal :)

Feina comercial

La primera història entronca en el que és el funcionament diari de l'empresa. Un client de Madrid ens demana un pressupost per a una aplicació web. És un empresa gran i vol que hi anem a presentar-nos. Té bones referències nostres però ens vol conèixer personalment.

No hi tenc cap problema amb que un client ens vulgui conèixer, la nostra oficina està sempre oberta i la cafetera engegada. Però vol que anem a Madrid en pocs dies de marge. Es pot arreglar, li dic, però ens haurà d'enviar els bitllets.

Això deixà el client descol·locat. Diu que això no ho fan, que són els possibles proveïdors que es paguen el viatge per anar a veure'ls. Li explicam que nosaltres no funcionam així i al final la reunió es fa per videoconferència.

Sé que això és una pràctica habitual, però el que em sorprèn és que alguna gent no sia conscient de que al final el que estarà pagant en el seu projecte no serà sols el cost de desenvolupament i direcció de projecte, sinó també el cost dels comercials engominats que l'aniran a veure. I el que és pitjor, estarà pagant el cos no seu, sinó el cost proporcional de totes aquestes visites comercials que s'han fet, s'han pagat i que no han resultat en una feina. En poques paraules, estaran pagant molt més doblers per a un desenvolupament sols per fet que a algú li agradi sentir-se afalagat o important.

Sé que la feina comercial és important, però la nostra màxima ha estat sempre mantenir un nivell de despesa supèrflua mínima i per tant no carregar els pressuposts amb la despesa extra que suposa tenir una munió de comercials l'objectiu del qual no és més que fer la pilota als possibles clientes i que moltes vegades no saben el que venen.

Curiosament pareix que el potencial client, que normalment no pagarà la feina amb els seus propis doblers, necessita d'aquesta cerimònia, no essent conscient de que tot això ha de sortir forçosament dels projectes que farà l'empresa que està avaluant.

Potser també som atípics amb aquest aspecte, però em resisteixo a aquestes coses i trob que si la relació comercial ha de ser duradora aquesta no es pot basar en "te faig la pilota i així em compraràs". Si jo he de perdre tot un dia per anar a veure't al manco hem de compartir despeses, ja que per mi no és just haver de carregar aquests costs damunt els projectes d'un altre client.

De la mateix manera quan un pressupost veig que ha de dur dies de feina i a vegades setmanes o mesos, no ens podem deixar enlluernar pel possible guany futur. Si un vol un pressupost anàlisi d'aquesta mena l'ha de pagar, de la mateixa manera que paga els plànols d'un arquitecte. En cas contrari estaríem novament carregant molts costs contra els projectes que sí es fan.

Òbviament a l'hora de calcular el cost per hora que s'ha de carregar per la feina s'ha de tenir en compte que sempre hi haurà un cost comercial, com hi ha un cost per la gestió de l'empresa o el cost associat per la direcció. Però per ser justs crec que tot allò que ultrapassi el que és raonable s'ho hauria de pagar el que ho demana.

Segur amb aquesta mentalitat no arribarem mai a tenir un Ferrari a la porta, però segur què hi farem...!

Festa d'Habitissimo

El divendres vaig anar a la festa d'Habitissimo. M'agrada veure com un equip de gent com aquest creix i li van bé les coses. Ja fan quatre anys i han pogut créixer a un ritme fantàstic, i a la mateixa vegada mantenir l'esperit viu, inquiet i innovador no és fàcil i aquesta gent ho està aconseguint. Estic molt content per ells i sempre és un plaer poder converçar amb Jordi i Martin. A més la festa va servir per poder saludar a amics com Hugo o Suki. Amb Suki un poc més i feim les tantes cotorrejant.

Empreses com Habitissimo per mi sí que representen el que hauria de ser una empresa en el Parc Bit. Supòs que no és tan cool com fer-se una foto davant el logo de Microsoft pels polítics, però sí que us puc assegurar que estan fent molt més pel teixit empresarial de la nostra illa que els altres. Potser si algun dia ens n'adonam tots d'això es podrà invertir realment en el que dona feina i és una alternativa real al monocultiu turístic.

Antibes

La gent d'ACREW va organitzar un event a Antibes d'allò més sonat, i ja sabeu com va això. S'han de crear noves planes per l'ocasió, mirar de tenir noves característiques llests, i fins i tot un canvi d'imatge i de tot el procés de registre.

Van ser dies intensos de programació, però el resultat s'ho paga. Molt bona acollida de l'aplicació, molts usuaris nous i una startup que creix. No sé si arribarà als nivells d'Habitissimo, però la veritat és que per l'esforç que hi està posant la gent d'ACREW s'ho mereixen.

La resta és més o manco el dia a dia. Pareix que ens estam especialitzant en donar suport a emprenedors, tant gent que vol montar el seu negoci per primera vegada com empreses que volen donar el pas cap a Internet, i això m'agrada molt. És un tipus de client fantàstic i s'estableix una relació de complicitat molt bona.

No ho sé, a vegades tenc la sensació que podríem guanyar més organitzant-nos com a una empresa clàssica de desenvolupament, amb comercials engominats especialitzats en vendre vehicles de dues rodes, però segur que no ens ho passaríem tant bé.

Un dels lemes que més m'agraden de Python, el llenguatge que hem triat per al desenvolupament es "Life is short, use Python", per què no aplicar-ho també a la feina diària?

Ahir vaig acabar de llegir "El japonés que estrelló el tren para ganar tiempo" de Gabriel Ginebra. Segons el subtítol intenta explicar el perquè ens tornam incompentents i com evitar-ho.

Ho vaig comprar en la seva edició Kindle, per poc més de 5 Eur. L'edició en sí es un poc descuidada, sovint no veus on comença un subcapítol i sembla que hi ha una línia desconnexa de la resta, la qual cosa resulta un tant molesta a l'hora de llegir.

Ginebra ens va mostrant les causes de la incompetència i els primers capítols són un resum del principi de Peter, lleis de Murphy i Dilbert, potser per posar-nos ja en guàrdia del que ens espera. Bàsicament ens ve a dir que tothom som incompetents, sia en un aspecte o altre i que el primer que hem de fer per millorar és ser conscient d'aquesta incompetència, abraçar-la i gestionar-la.

Fa molt èmfasi en com la sobrecompetència genera la incompetència. Voler arribar a la perfecció sense tenir en compte que vivim en un món imperfecte, a base de normes, procediments i sancions el que fa es generar renou i aconseguir l'efecte contrari del que volíem.

L'autor ens diu s'han d'eliminar capes de procediments, que la direcció de les empreses s'ha de concentrar amb gestionar les persones amb les persones, i no viure en una torre d'ivori practicant una mena de despotisme il·lustrat. És el que anomena el management amb minúscules.

Realment el que exposa Ginebra és del tot lògic i raonable, però no per això deixa de ser necessari exposar-ho i repetir-ho fins que la idea s'assenti. La meva pròpia experiència en les empreses en que he treballat m'ha permès veure molts tics que assenyala l'autor, així que hi hagi veus autoritzades que tracten el tema trob que sempre és bo.

Encara que el llibre en el seu conjunt és clar, si bé en alguns casos cau massa en l'anècdota, hi ha un capítol que ha quedat entre confús i contradictori. És el capítol 8 titulat "Trabajar lo peor posible". És un títol i una argumentació poc afortunada tal com s'expressa. Personalment la resumiria en aquella frase que diu que no hi ha res pitjor que fer de manera eficient allò que mai s'hauria d'haver fet. Això no vol dir fer feina el pitjor possible, sinó ser a la vegada intel·ligents i peresosos, saber treure el màxim rendiment de l'esforç i no crec que tengui res a veure amb treballar el pitjor possible. El fons del capítol està en aquesta línia, però trob que "The lazy project manager" tracta molt millor el tema i de manera més argumentada i menys contradictòria. En descàrrec de Ginebra val a dir que ell dedica un capítol a l'argumentació i l'altra és un llibre complet. El que sap greu és que és un capítol que no està realment a l'alçada de la resta.

M'han agradat especialment els capítols destinats a l'empresa barroca, el com una empresa va sobrecarregant-se, com els seus treballadors i directius van creant-se tasques del tot innecessàries per tal d'autojustificar-se. L'anomena el "Síndrome del demasiado tiempo libre". També són prou clarificadors els darreres capítols, destinats a les relacions humanes, a com gestionar persones i equips, el tracte humà, el parlar amb la gent, el poder-nos gestionar l'agenda de manera que s'ha de fer lloc per estar per la gent.

En resum, un llibre interessant, clarificador i bo de llegir, Potser massa llarg i tot pels pocs, però importants, conceptes que tracta. Força recomanable.

En el darreres setmanes hi ha força enrenou a la xarxa referent al món informàtic: web multimilionàries que algú diu que faria per 500 €, queixes constants del sous o no sous. Fins i tot en David Bonilla a la seva llista diària se'n fa ressò, dient que en molts de casos és una estratègia per aixecar polseguera i aconseguir enllaços i posicionament. En alguns dels darreres apunts que he llegit no us diré que no, ja que en la discussió fins hi tot hi havia EL TROLL, que no va ser moderat en camp moment pel propietari del blog que havia iniciat la polèmica. Potser sí que en Bonilla té raó.

Això de totes maneres ve molt de passada amb el que volia parlar avui, que és del tema becaris. Fins ara a la nostra empresa hem tingut dos becaris: Juan, un amic de fa anys que feia un curs i cercava una empresa "seriosa" en la que realment pogués aprendre alguna cosa a la seva cinquantena d'anys i en Pau, becarium infinitum com ell mateix se defineix, que està amb nosaltres com a becari mentre acaba el projecte de final de carrera.

Agafar un becari per mi és una responsabilitat gran. No és algú que t'ha de fer els cafès o fer fotocòpies, o a qui i pots encarregar les tasques que ningú vol fer. Un becari fa una feina per l'empresa a canvi d'una supervisió i un aprenentatge.

L'empresa es pot aprofitar dels més baixos del becari en les cotitzacions socials (zero de fet) i a canvi d'això ha de donar al becari una formació laboral que potser li manca quan ve des del món acadèmic. Per mi això implica assignar-lo inicialment a un projecte intern o sense risc ni plaç d'entrega, poder supervisar el codi que s'escriu, corregir-ne els errors i estar disposat a contestar totes les preguntes que es facin.

Conforme el coneixements van augmentant la supervisió ja no fa falta que sigui tan a nivell micro i es pot anar assignat a aquesta persona a projectes amb més grau de responsabilitat. Sols amb aquesta progressió obtindrà la formació adequada, ja que si al llarg de la beca no pot integrar-se a un projecte normal, voldrà dir que l'etapa d'aprenentatge inicial no ha estat prou bona. Integrar-se en un projecte amb risc i dates d'entrega vol dir poder viure el dia a dia d'un projecte real, amb errors que s'han de corregir, amb codi que s'ha de mantenir, col·laborant amb altres programadors i entrant dins la dinàmica habitual de l'empresa.

Com podeu veure ser un becari a APSL no és cap bicoca, implica molta feina tant pel propi becari com per l'empresa. I trob que és així com ha de ser. El becari ha de ser rendible per l'empresa després de la inversió que fa aquesta en la seva formació, però aquesta inversió hi ha de ser sí o sí. Ser becari ho entenc com una responsabilitat de les dues parts.

Segurament per això ens hi miram tant a l'hora d'agafar-ne de becaris. Hem de tenir temps per dedicar-los i projectes adients on puguin aprendre. Sovint tenim ofertes d'empreses de formació que ens volen enviar gent, on fins i tot hi ha una subvenció de l'estat per tenir-los, oferint-los com a ma d'obra barata. No gràcies!

Si el becari acabarà essent rendible per a l'empresa el becari ha de cobrar i el sou ha de ser adient amb la seva formació, amb els resultats que s'esperen i tenir en compte també el cost de la formació interna que rebrà. Curiosament al nostre país si vols pagar un sou decent a un becari pots tenir problemes (així ens ho va dir la gestoria) ja que es pot considerar que no és una relació d'aprenentatge sinó una relació laboral. En canvi, si a un becari no li pagues res, el tens putejat fen feina que no vol ningú i no en fas el seguiment i la tutorització, doncs no passa res, és el que tothom espera.

Doncs a fer punyetes el que tothom espera! Personalment seguiré amb aquestes idees, i amb la idea que un becari format a APSL és una inversió de futur tant per ell com per a la pròpia empresa, ja que en cas de que la feina creixi, qui millor que incorporar-se a ella que algú que ja sap de primera mà com funciona?

Un becari a més significa sang nova, un punt de vista diferent respecte de com es fan les coses. Sols el fet de tenir que explicar-les a algú ja fa que et puguis replantejar si allò que estàs fent té sentit, si hi ha maneres de fer-lo millor. I també és una oportunitat d'aprendre. Amb Pau, per exemple, una part del grup d'APSL va passar a sistemes d'escriptori Linux basat amb Tiles i fins i tot em vaig deixar convèncer per tenir una Debian unstable al portàtil.

Potser quan aquesta manera de fer les coses sigui la norma i no l'excepció el nostre sector començarà a canviar. Sempre he trobat que per intentar canviar les coses el millor que es pot fer és practicar amb l'exemple. Jo vull tenir becaris que s'enorgulleixin de poder dir que començaren a l'empresa des de becaris o que si per les raons que siguin ja fan feina a APSL puguin posar-lo ben gran al seu currículum.

Aquests començament d'any ha resultat ser força més mogut del que m'esperava. Mogut en el sentit positiu: pareix que hi ha força projectes grans en marxa i bones perspectives. La gent es va animant i demana pressuposts, que ja veurem si després sortiran o no, però davant l'apatia del 2012, és un bon senyal. Potser ja ens hem acostumat a viure en un estat de crisi perpètua.

De totes maneres el 2013 es presenta complicat, la pujada d'IVA dels darrers mesos fa que cada factura impagada sigui un risc. Si el 16% ja ho era, ja no us dic res del 21% i si la quantitat és gran te pot deixar ben fumut. Si això ho sumam que ara reclamar factures per via judicial sortirà molt car, doncs ja tenim la combinació perfecte per a que petites empreses i autònoms estiguem amb l'ai al cor cada vegada que començam un projecte.

Aquest començament d'any té un altre efecte: fa un bon grapat de setmanes que no em puc dedicar a temps complet a programar. Fer pressuposts amb cara i ulls requereix temps i dedicació que no pots compartir amb la concentració que representa programar. En programar tens les mans en un problema actual, en resoldre una feina, quan fas un pressupost tens la ment posada en el futur, en possibilitats i estadístiques. Pens que és un estat mental diferent i és complicat passar d'un estat a un altre, sumat ja a la complicació inherent a estar "en la zona" quan programes.

La veritat és que m'agrada molt programar i en part és per aquesta sensació de concentració i pau mental que tens quan programes. Fer un pressuposts o gestionar projectes també m'apassiona (sóc així de raret) però el cuquet hi és.

Hi ha gent que quan l'empresa ja va bé, es compren un cap administratiu, per a que gestioni l'empresa i ells poder-se dedicar a programar. Nosaltres no hem crescut tant, però de tant en tant pens que seria prou divertit això, però tanmateix pens que com a empresa tecnològica, la responsabilitat de fer els pressuposts no es pot deixar en mans de personal administratiu sense coneixements del que està fent, així que ara per ara me pareix que hauré d'intentar combinar els dos capells.

Potser el que sí hauria de fer és anar trobant nous talents que es puguin incorporar al grup. Els set integrants d'APSL formam un equip del que puc presumir, no tan sols per la feina que fem, sinó per la manera d'entendre l'empresa i el treball informàtic. S'assumeixen els riscs i les alegries de la feina. Vivim en un estat d'startup permanent, però sense les rondes de finançament, i això fa que mai poguem caure en la monotonia i l'avorriment. Vaja, que ens ho passam bé!

Pau, una de les nostres darreres incorporacions al grup, deia que el seu entorn el mirava estranyat perquè cada dia va a fer feina content. És l'esperit que s'ha d'aconseguir en una feina com la nostra. Que acabis la feina d'un dia amb ganes de tornar-hi al dia següent. Hi haurà dies bons i dolents, però el més important és llevar-se amb la il·lusió i les ganes. Amb això la feina hi fa molt, però també l'esperit de la persona.

Aquest mes de març començaré el cinquè any de l'aventura d'APSL, estic fent el que m'agrada, passant pena, fent feina dia a dia, intentant guanyar-me la vida fent el que m'agrada, tot i l'entorn poc favorable a les petites empreses com la nostra i als autònoms en general. Mostrant que les coses es poden fer d'una altra manera, que es pot viure programant amb programari lliure i amb l'ètica del programari lliur, que es pot fer feina treballant amb Python i Django, i que la suma del grup és major que la suma de les parts.

Veurem com va el 2013. També he de fer un pensament, i és contar un poc més coses de Python i Django, que darrerament hi ha força coses interessants: una PyconES que es prepara, el nou Django 1.5, llibreries i utilitats, ... Ens anam llegint! Esper que per vosaltres que em llegiu el 2013 sia també un any digne de viure's.

Ja som a un punt on hem decidit que hem de fer el pressupost, l'hem fet i hem fet les nostres primeres estimacions.

L'estimació del pressupost ens haurà donat un nombre, el significat del qual dependrà de la metodologia d'estimació utilitzada, però que finalment haurem de convertir en hores-home i aquestes hores home en una quantitat monetària.

Podria parèixer que amb això s'acaba tot, però si ens aturam aquí ens trobarem que les nostres estimacions estan força lluny de la realitat.

A més de la feina bàsica de programació s'han de tenir en compta tot una conjunt de factors que afecten a l'hora d'entregar el pressupost final, tant en temps com en doblers.

El temps mínim i el temps òptim

Tots coneixeu l'acudit que encara que una dona pugui donar a llum un nadó en nou mesos, nou dones no el fan en un mes. En tot projecte informàtic hi ha un temps mínim d'entrega, que depèn tant de l'equip de desenvolupament, com del propi client o de qui ha d'anar resolent dubtes i subministrament continguts.

El temps mínim sovint coincideix amb el cost màxim. Vull dir, per assolir aquest temps mínim l'equip ha de ser més gran (fins a un màxim) i això implica més tasques de coordinació i una menor optimització de recursos. La velocitat de desenvolupament no és proporcional el nombre de programadors, sinó que arriba un moment que per mols programadors que posem el projecte no avança més ràpid, sinó que fins i tot pot endarrerir-se.

Així doncs en el nostre projecte hem d'establir quin és el temps mínim que podem tenir, amb el nombre de programadors màxim i el temps òptim en costs, que és aquell que permet entregar el projecte més tard, però amb un cost de programació menor.

A partir d'aquestes dues escales hem de saber quines són les necessitats del client i si encaixen en els temps prevists. El pressupost, per tant es veu afectat també pel requeriment d'entrega.

La direcció del projecte

En un projecte gran m'agrada fer visible la feina de direcció i de coordinació del projecte, i encara que potser sigui poc comercial posar una quantitat per la direcció de projecte trob que hi ha de ser. D'aquesta manera tothom és conscient que al llarg de la vida del projecte hi ha d'haver reunions internes i reunions amb el client, i que aquestes estan contemplades dins la tasca com a una activitat més.

En projectes petits aquesta tasca pot significar un 10% del total del projecte, en projectes més grans pot arribar perfectament a un 25%. Així que no considerar aquest factor ens pot dur a una desviació del pressupost molt difícil de superar.

El nombre final que s'ha de considerar dins la direcció del projecte també té molt a veure amb l'estabilitat dels requeriments. Si el projecte té unes fites molt clares, les necessitats de reunions per anar aclarint els punts són molt més curtes i profitoses que en les de projectes on les fites són més difuses.

Altres costs associats al projecte

A més dels costs que tenim en feina de programació hem de pensar que a més tenim tota una sèrie de costs que s'han de repercutir d'una manera o altra en el projecte. Sovint aquests costs ja es consideren dins el preu-hora aplicat a l'hora de donar l'import final, però hi ha projectes que tenen els seus propis costs que s'han d'avaluar.

Dins els costs normal tenim:

• Cost de local: lloguer, llum, telèfon, Internet, assegurances.
• Material d'oficina
• Amortització de l'equip informàtic
• Despeses de gestoria i administració
• Despeses financeres

La majoria podem considerar-les com a despeses fixes i posar-les dins el cost-hora, però hi ha casos en que el projecte es molt gran i per exemple el tema de les despeses financeres pot ser molt important. És una de les raons del perquè els projectes públics solen costar molt més: el proveïdor ha de tenir en compte que haurà de fer front a moltes despeses que sols cobrarà al cap d'anys (si hi ha sort), això genera una despesa financera que s'ha d'avaluar i imputar al projecte.

Suposem que tenim un projecte que requereix que agafem més gent. Dins aquests projecte s'ha de considerar també la despesa que representa la selecció de personal, l'amortització del nou equip que necessitarà i el període de formació.

Quan més gran és el projecte més coses hem de tenir en compte si volem donar una aproximació en costs i temps el més acurada possible. Mirar al futur és complicat, cert, i pensau sempre que sols és una aproximació.

Abans d'entrar en matèria i fer càlculs hi ha un requisit previ, que és saber què és pot pressupostar i que no. I com diu Jordi a un comentari de l'apunt anterior, sovint convé saber primer si convé fins i tot dedicar temps a fer el pressupost.

De vegades m'he trobat amb gent que demana un pressupost d'un projecte sense tenir-ne clar l'abast o ben bé què demana. Tanmateix podria estar demanant què li costaria posar en òrbita un satèl·lit, amb la diferència que per això, com que ja s'ha fet es pot tenir una idea.

Sovint, i més en entorns d'emprenedoria i noves idees, se'ns demana que pressupostem un programa que no s'ha fet mai, del qual no se'n tenen referències, o l'abast del qual és tan gran que el pressupost sol necessita un pressupost.

Fa poc vaig tenir que dir a una persona que no li podia fer un pressupost. La seva llista de requeriments era un gràfic, no podia contar massa més, no sigui cosa que li pentinàs la idea (sic!) però que necessitava un pressupost el més acurat possible, encara que admetia que després hi podria haver un % de variació.

Què fas en un cas així? Doncs jo dir que no, que això no es pot pressupostar i que o hi ha més informació no no es pot fer res.

Així doncs, a l'hora de fer un pressupost el que necessitam és una informació el més acurada possible del projecte i del seu abast. Si el client no té clar que s'ha de fer, també ha de tenir clar que el pressupost sols pot ser una declaració d'intencions. No passa res, és perfectament assumible fer un pressupost orientatiu si el client té clar que la realitat pot diferir molt del que s'ha dit. L'experiència, però, és que el pressupost fixa un preu en la ment del qui el demana i si després el projecte es desvia molt hi ha problemes. El millor per mi és tenir al manco un mínim d'informació, si no es té, enlloc de tirar-se a la piscina, consider que és més ètic rebutjar fer el pressupost, ja que no hi ha cap garantia que tingui un mínim de fiabilitat.

Com pressupostar un projecte que no s'ha fet mai.

Suposem ara que ja tenim prou informació. Seguim amb el problema bàsic, que és que hem de pressupostar una cosa que no s'ha fet mai, que potser nosaltres no hem fet mai o bé que la tecnologia és tan nova que no hi ha cap referència o guia per la qual guiar-se.

Aquí la pregunta a fer-se és, qui assumeix el cost de la desviació si hi és? És una bona pregunta, veritat? Això condiciona el pressupost i el projecte. En projectes novetosos crec que no és el desenvolupador qui ha d'assumir aquests costs, ja que s'està posant sobre l'esquena del desenvolupador una responsabilitat que no li correspon, per tal de complir un pressupost o uns plaços que no tenen cap base.

Això no vol dir que no es pugui pressupostar, però com deia, s'ha de tenir molt clar que el pressupost és una referència i no un nombre tancat. Com a referència servirà per a que el client pugui fer-se una idea inicial de l'abast del projecte, però per ser justs el pressupost hauria d'anar a hores i/o fites. De manera que el risc tant del client com del programador es minimitzi. Del client perquè pot anar avaluant l'avanç del projecte i veure que paga conforme veu resultats. Pel programador o per que l'ha de pressupostar, perquè no es veu en l'obligació de tenir que fer una estimació a l'alça per tal de no agafar-se els dits.

Dit això, l'estimació que m'agrada és aquella en la qual hi ha alguna cosa que es pugui comptar. Vull dir, enlloc d'aixecar un dit a l'aire i dir "costarà tant", millor si ens aturam una estona i pensam com podem obtenir alguna cosa quantificable del projecte que ens permeti avaluar-lo, classificar-lo i extreure'n una primera estimació.

Si el client duu el disseny podem basar-nos en les pantalles, en el nombre d'interaccions, amb el nombre de casos d'ús, en el nombre de taules, en el nombre de missatges a mapejar. Sigui com sigui això ens ha de poder donar una idea de la complexitat del projecte i evitar donar una xifra basada en la nostra apreciació de si es fàcil, difícil o de l'estat d'ànim que tinguem aquell dia. Si es pot basar un pressupost en una mesura s'ha de fer, encara que ens dugui més temps, si no es pot basar en res, ens hem de plantejar si es tracta d'un pressupost d'aquells que convé no fer o bé si convé cobrar per fer l'anàlisi previ del projecte i a partir d'aquí tenir el pressupost.

Pressupostar feines semblants

La programació a mida té una cosa que la fa interessant que és que sempre hi ha variacions. Tot i això sovint ens podem trobar amb projectes que s'assemblen molt a projectes que ja hem realitzat.

En aquest cas ja tindrem dues vies d'estimació. Per una banda els càlculs que puguem fer i per altra la història del projecte semblant. De les dues coses segurament sortirà un pressupost molt més acurat que si sols ho fem d'una.

Si sols agafam com a referència el projecte anterior ens trobarem que no hem tingut en compte les variacions que potser no són tan mínimes com pensàvem,

Com deia abans el pressupost no ha de significar forçosament tancar tots i cada un dels detalls, però si el client que et demana un pressupost ho fa pensant que té un pla de negoci, que ha de saber de què ha de morir i per tant tampoc ho fa per caprici. Si optam per fer el pressupost pens que s'ha de fer de manera que la xifra que donem sia el més raonable possible.

Si no podem fer un pressupost explicar-ho, i explicar que es pot anar a hores fins que es pugui tenir una idea més clara de la feina que s'ha de fer i donar una estimació final.

Qui ha de fer el pressupost?

En altres contrades que fa un pressupost sol ser el comercial. Si anau a comprar un cotxe el pressupost us el farà el mateix comercial, en altres productes tangibles també. En la part de programari a mida, la cosa no està tan clara i sovint serà necessari i convenient que sia algú més proper a la feina qui pugui fer el pressupost.

Personalment crec que si es pot han de ser sempre la mateixa persona o el mateix grup de persones que facin els pressuposts. Per una banda es va guanyant experiència, però sobretot permet a cada un anar coneixent les desviacions que fa i anar compensant-les.

Quan és sempre la mateixa gent que fa un pressupost poden pensar que es seguiran sempre criteris semblants i això evita sorpreses a la llarga. En un món ideal tindríem més d'una persona fent un mateix pressupost i podríem discutir el perquè i arribar després a un pressupost consensuat. En projectes mitjans (que poden ser grans en una escala PIME), els recursos són limitats i per això l'especialització en fer pressuposts trob que és necessària i convenient.

Ens queden els càlculs

Molt bé ja tenim els primers càlculs fets, ara ja tenim una petita idea de per on van els tirs. Perfecte, doncs ara ens queda adaptar aquestes xifres a la nostra realitat.

Si no us he avorrit molt miraré de parlar-ne al proper apunt.

Una de les tasques que hem de fer la gent que ens dedicam a la programació d'aplciacions a mida és la de tenir que dir què costarà fer l'aplicació, és a dir, fer un pressupost, i d'això tractarà aquest apunt, de com entenc jo que ha de ser un pressupost de programari, de les dificultats de fer-ho, del tipus de pressupost que es demanen. Com sempre, esper no avorrir-vos molt.

Què hem de posar a un pressupost?

Això és una de les qüestions més delicades. El més habitual en el nostre sector és que els pressupots no es cobren, per tant hi ha dues visions contraposades: la de dedicar el mínim temps possible a fer el pressupots i la de fer un pressupost amb cara i ulls, de manera que les xifres que es posin allà estiguin justificades amb la feina que s'han de fer.

Particularment sóc partidari de la segona opció. Pensau que la feina final no és el pressupost en sí, sinó el projecte que sortirà d'aquest pressupost. Per això és important que el pressupost defineixi ja l'abast de la feina, els objectius del projecte, el seu abast i les condicions en que es durà la feina.

Per això és necessari tenir força informació del projecte, saber què s'ha de fer en línies generals. Vull dir, no es tracta de saber-ho al detall tot, però sí de ser molt conscient de què és el que cerca el client amb l'aplicació i quines són les feines fonamentals que ha de fer.

En aplicacions web normals això pot ser tan simple com pensar el sitemap de l'aplicació i anar posant-ho damunt el pressupost. "La plana home mostrarà les ofertes principals, amb les imatges dels productes que es motraran de manera aleatòria, ..."

En altres tipus d'aplicacions molt més orientades a la gestió el sitemap de l'aplicació encara no està clar en aquesta etapa i llavors convé fer una mica d'anàlis dels casos d'ús que hi ha implicats.

Una vegada hem redactat el que es farà a mi m'agrada posar també amb quines condicions es farà. És a dir, que el client sàpiga que un projecte web és cosa de les dues parts, que hi ha feines que ha de fer l'empresa de desenvolupament, però que l'èxit del projecte també pot dependre de la seva pròpia implicació i dels tercers involucrats en el projecte.

Després d'això les xifres econòmiques. Jo he estat a les dues bandes, i no m'agradava gent tenir sols una xifra final sense cap tipus de suport lògic. Per això m'agrada sempre indicar el perquè de la xifra i si és possible desglossar-la per tal que el client pugui veure les implicacions de feina de cada concepte.

No es tracta d'anar al detall fi i tancar-ho tot, però sí que s'ha de ser conscient de que per exemple hi ha una feina de sistemes en el projecte, que hi ha feina de gestió, de maquetació, ...

Finalment la part de parrafada de les condicions: fins quan dura el pressupost, quan es dona per començat, com seran els pagaments, com es gestionaran les modificacions, quines garanties hi ha.

Aquesta darrera part és bastant aprofitable entre diferents projectes, però sempre hi ha condicions particulars per a un pressupost concret.

Fet i fent, doncs un pressupost pot dur força feina, entre mig dia per a un projecte senzill, de posem un mes de feina, a varis dies per projectes més complexes.

Cada un ha de tenir el seu límit personal que separa el que és un pressupost i el que és un anàlisi complet. Si la feina de pressupostar requereix d'un anàlisi complet i investigació, crec que és una feina que va més enllà del que és fer el pressupost i que s'han de cobrar com a feina de consultoria.

Jo he vist pressupots d'una plana!

I jo també, i fins i tot hi ha clients que agafen aquests pressuposts, però després tots ja sabem com solen acabar aquestes coses.

Pens que hem de ser molt transparents en la feina que fem i donar sols una xifra sense explicar la feina no és bo ni per al professional ni per al client.

Per al professional perquè pot donar l'impressió que s'està inventant la xifra, perquè no està dient què farà i això a la llarga pot causar molts problemes i perquè si li accepten un pressupost així acabarà amb clients que no valoren la feina feta sinó que simplement van a un preu final sense saber què hi ha al darrera.

Fer pressuposts a alguna gent li pot parèixer que es perdre el temps, però jo no ho veig així. Força al programador i al client a pensar en el que volen, a definir unes regles del joc.

Pensau que no és gens habitual passar de pressupost a contracte, així que normalment el que defineix l'abast de la feina és el pressupost i per tant aquest és el document que fixa la filosofia de feina de l'empresa.

Fer un pressupost i el desenvolupament àgil

L'altra dia vaig fer un twitt dient que havia entregat un pressupots de gairebé 20 planes i un seguidor em deia que això no seria molt àgil. No té res a veure. Un pressupost aixì indica que l'apliació és complexa, que durà mesos de feina, però no és un anàlis "en cascada".

El manifest àgil no diu res de fer pressupots, ens diu que hem de donar prioritat als indivíduu front als processos, al programari front a la documentació, a la col·laboració amb l'usuari davant la negociació de contractes i a respondre als canvis.

I hem de poder fer això donant una xifra al client. El manifest no diu res de "no te diré què costa fins que estigui acabat", sinó que la idea que hi ha al darrera és que sempre es procurarà que el programa que entregui respongui a les teves necessitats, encara que no siguin las mateixes que quan començarem el projecte.

Un pressupost és el punt de partida, el que diu què volem fer i estableix el llenguatge comú del projecte. El que les dues parts pensen que s'ha de fer. La col·laboració amb el client i la resposta a canvis es té quan fas que el pressupost no sigui inamobible, sinó que es puguin anar afegint o llevant funcionalitats segons siguin les necessitats del projecte.

Quan el client coneix les regles del joc, sap que la xifra que li has donat és una estimació, però que els canvis no se li cobraran sempre, sinó que si un canvi implica que una altra funcionalitat no es fa, es probable que les xifres es compensin, i és més, com que té el pressupost on hi ha les tasques i la seva complexitat, pot avaluar per sí mateix l'impacte dels seus canvis en el cost final de l'aplicació.

El pressupost estableix els supòsits de partida, és la validació que s'ha entès la feina que s'ha de fer, però en cap caps significa que una vegada acceptat impliqui que allò és just el que s'ha de fer i que "ja ens veurem quan t'ho acabi". Estam complint un dels principis del manifest àgil, valorant més la col·laboració i la implicació del client que signar el contracte final. i informant-lo al mateix temps de la flexibilitat que té per anar canviant el projecte així com vagi veient la seva evolució.

Posant preu

Si heu anat aquí directament millor tornau enrera :) Als paràgrefs anteriors estava dient que per posar preu hem de conèixer el projecte i establir com col·laborarem amb el client.

Posar preu és complicat. Se'ns demana que adivinem quina feina durà fer un projecte que no hem fet mai, que anticipem problemes, ho valorem en temps i esforç i que al final posem una xifra.

Si no hem definit abans quin és el significat d'aquesta xifra i el client enten que la xifra és el projecte anam malament.

En el proper article mirarem de veure com posam preu, si convé tirar de bolla de vidre o podem fer alguna cosa més a l'hora de definir un preu per al projecte.

Ens llegim aviat!

Doncs sí, han estat un bon grapat de dies dedicant-hi moltes hores, sobretot a casa i a hores mortes, però finalment avui, o millor dit ahir als voltants de les 19:30 apareixia la versió d'Spokenpic al Google Play.

Ara hem de veure quina acollida té dins un públic més ample que els beta-testers que han estat provant l'aplicació, als que aprofit per donar una vegada més les gràcies.

Ara comença també un procés de millora, de la web, de noves característiques, ... Però abans de res gaudir uns dies de la feina feta i veure les primeres impressions de la gent.

Al final amb una aplicació així són els propis usuaris els que diuen si els interessa o no.

L'aplicació estava enllestida per fer les cridades asíncrones a Twitter i Facebook, però suposàvem que en el llançament no faria falta. Doncs mira per on quin dia ha elegit Twitter per caure. Afectava negativament al rendiment de l'aplicació.

Després de tot ha anat bé perquè hem detectat i corregit un error a l'aplicació i també ha servit per a comprovar que la API encara que més lenta, no cau per una caiguda de Twitter.

Demà de totes maneres ja hi haurà posat el Celery amb Redis i així aquest temes estaran molt més controlats i la caiguda de Twitter o Facebook no tindrà efecte en la velocitat de l'aplicació.

També ens queda anar vigilant el Sentry, el sistema de monitorització d'errors que utilitzam, per a controlar les petades no previstes i resoldre els problemes que segur que aniran sortint.

I és que les petades no previstes no ha de passar desapercebudes, això de posar un try/except i caçar-ho tot és molt mala pràctica, és millor tenir un sistema com Sentry que ens informi de tot el que no hem previst.

El primer que hem detectat ha estat un nom de plantilla mal posat. Un typo, que hem pogut resoldre en pocs minuts. Insisteixo, si no feis servir fabric per als desplegaments estau malbaratant el vostre temps. S'ho paga anar creant les funcionalitats per a poder desplegar aplicacions ràpidament.

A veure si puc treure temps per parlar per aquí del Tastypie, dels problemes que m'he trobat fent l'API de l'Spokenpic, i els avantatges i mancances d'aquest bastiment Rest per Django.

Avui també he fer servir una eina, per un altre projecte, de la qual també tenc moltes ganes de parlar, ja que m'ha sorprès per la seva utilitat a l'hora de resoldre un problema com és el de la migració de dades, és un ORM molt lleuger anomenat Peewee.

Aquestes festes nadalenques he aprofitat per llegir un poc. M'havien recomanat el llibre "The lean Startup", així que el vaig comprar per Amazon i encara que vaig començar a llegir-lo abans de festes vaig aprofitar la tranquilitat d'aquests dies per fer-li una bona llegida.

El llibre està força bé, però com que ja havia llegit el de "Lean development" doncs he trobat que molts conceptes són comuns i les històries bàsiques que fan referència a l'experiència de Toyota repetides. Però per la gent que tingueu curiositat per aquest concepte el Lean i no el vulgueu aplicar directament a la programació, doncs és un llibre força interessant.

Tanmateix el focus de llibre, tot i que farcit d'exemples per fer lo entenidor, gira entorn a un grapat de conceptes bàsics:

• Fugir de tot el que no sigui necessari per al negoci.
• Esbrinar el més aviat possible si el que feim és el que el client vol, llançant el mínim producte viable.
• Aplicar el mètode científic a les millores i experiments que fem. És a dir, mesurar el que serveix per a millorar el negoci i no el que serveix per a millorar els nostres egos.
• Arrel de tot això, no tenir por en canviar de direcció, de pivotar, si els resultats que tenim a partir dels nostres experiments així ho indiquen.
• Anar a cercar l'arrel del problema enlloc de cercar culpables.

Si ens hi fixam tot és com a molt lògic. Posar-ho sobre paper i llegir-ho, però ens obliga a reflexionar-hi. Quantes vegades estam desenvolupant un producte i afegint més i més característiques sense saber si tindrà o no èxit? En una empresa a la que vaig fer feina, teníem un producte llest per surtir, però els responsables de producte no volien sortir sense una característica molt determinada, el "así no salimos" es convertí en una frase mítica. Potser si haguessin llegit aquest llibre (o un de semblant) el producte hagués sortit dos anys abans i s'hagués guanyat un temps preciós a l'hora de saber si el que es volia fer era viable o no.

Personalment la metodologia Lean m'agrada molt. Estic molt acostumat a pensar d'aquesta manera, i això, us aviso, duu molts de problemes quan penses així a empreses on fer "les coses com sempre s'han fet" es converteix en l'objectiu fonamental. Una altra anècdota, fen una petita auditoria de processos em vaig trobar amb una gent que feien quatre còpies d'un document i les arxivava totes. Quan vaig demanar el perquè, la resposta fou la que us deia. Realment sols es necessitava l'original i la còpia, va costar però eliminar les tres còpies restants, amb la quantitat de documents que es movien segurament va salvar més d'un arbre.

Des del punt de vista del qui monta una empresa, és a dir, de la meva pròpia empresa, procuram sempre aplicar aquests principis. Ja us dic, la persona a la que consider la meva mentora en temes empresarials en José González té aquests mateixos principis a l'hora de gestionar i organitzar una empresa. Si fos japonès segurament ara estaria fent conferències per mig món, aquí tenim/teniu el luxe de tenir-lo com a professor associat a la UIB. Si teniu l'ocasió i podeu agafar la seva assignatura com a lliure configuració i conèixer crec que no en quedareu decebuts.

Me n'he anat per les bardisses. Seguint amb el llibre, encara que la filosofia està molt bé, te queda un regustet un poc amarg. És en el punt on posa exemples d'empreses que aconsegueixen la seva ronda de finançament, del com poden créixer o muntar un negoci online. Després quan ho compares amb les pròpies dificultats per dur endavant un projecte et quedes pensant si aquestes coses sols poden passar en països llunyars, on hi ha empreses que paguen a consultors per fer conferències per tant de millorar l'eficiència del seu negoci, on hi ha finançament de "bussines angels", on les administracions no suposen que tots som un xoriços, ... bé no segueixo que m'agafa la depressió.

En conclusió, un llibre entretingut, amb conceptes molt interessants i tal volta un poc passat de pàgines. Trèieu la part on parla de finançament i perfectament es pot aplicar a una empresa d'aquí.

Reflexionant

Aprofitant que avui és una jornada de reflexió me pareix que aprofitaré per repassar un poc l'anecdotaria personal d'aquestes darreres setmanes, a veure si en puc treure també algunes conclusions.

No sé el que vull

Donc així ens va venir una persona a veure'ns i d'entrada em va amollar aquesta frase. Bé, res a dir, això és bastant típic quan es comença un projecte. El client no sap massa bé què vol, i la meva feina sovint consisteix en anar fer preguntes, clarificant el que el client vol. Al final, després d'hores de conversa vaig definint el que podria ser el projecte: gran, molt gran. El client resulta que nos sap què vol, però sap que ho vol tot!

Paralant parlant ens diu que ja té un altre pressupost. Diu que ens ho enviarà per a que li poguem pressupostar el mateix. Fantàstic, al manco hi ha un punt de partida. Al dia següent em pos a repassar les notes i començar a fer el pressupost. Quan m'arriba l'e-mail del client jo ja duc com a 8 fulles del pressupost, explicant què tindrà el programa d'acord amb les especificacions del client.

El pressupost que reb em deixa de pedra. Es tracta de dues fulles ròniques que sols inclouen un llista de manteniments, sense entrar en cap tipus de detall. Ja me fa mala espina que en la maraca d'aigua de la fulla hi ha un disquet (are you from the past?), doncs pareix que sí. Però el que em sobta més és el preu que hi han posat, com a deu vegades menys que el que a mi m'està sortint. Li faig una ullada, no s'incluen caps de les característiques que fan més complexa l'aplicació, pareix un conjunt de planes estàtiques amb un editor html al darrera.

Faig una ullada a la web de l'empresa i veig la feina que han fet. En aquests casos sempre pens que potser sóc jo qui m'he errat. També confirm amb el client que el que vol és realment el que m'ha demanat i no simples planes estàtiques o picades a un cms.

La web de l'empresa és per sucar-hi pa. Webs de fa un any o dos que estan fetes fent servir cgis. La plana 404 de les aplicacions apunta al proveïdor del hosting, que obviament es un d'aquests superpoblats, que aprofiten el darrer cicle de CPU per posar-hi usuaris. Anam a veure una de les webs i li coment a Juan lo del cgi i les petades. Ell a més me comenta que ha canviat un paràmetre de la url i li ha sorti un dump de base de dades. Aquesta gent no ha sentit mai parlar d'injecció de codi ni llegit Exploits of a Mom. Som bona gent i el seus clients no es mereixen tanta incompetència, així que ho deixam anar.

Ara ja tenim un problema important, que és el factor psicològic de la fixació de preu. Aquesta gent ha fet un pressupost sense tenir la mínima idea d'on s'estava ficant i del que realment volia el client i ha donat un preu fruit de la seva inexperiència. Ara quan el client vegi el que jo li presentaré es pensarà que li estic prenent el pèl encara que és just al contrari.

Primera conclusió: els clients en general estan molt verds a l'hora de demanar un programa. Quan un demana una casa s'informa del constructor, demana el que ha fet, en quin tipus de projectes ha participat, demana a les amistats i s'assegura que les cases que ha fet no han caigut. En el desenvolupament sols pareix que es fixa amb el color de la façana. Com a informàtics ens fa falta fer molta feina de pedagogia, d'ensenyar als nostres clients a comparar, a saber que hi ha feines més i menys complexes, a poder destriar amb qui se la juga.

El meu cap diu que té un conegut que ...

Aquesta també és una altra història en línia amb l'anterior. Faig un pressupost força ajustat, el projecte m'interessa, pot ser divertit. El client vol donar el pas cap el negocio online. Vol canviar la seva web actual potenciant-la i afegint-li venda on-line. Es preveuen cents de milers de planes servides al dia i la web hauria de funcionar 24x7 pràcticament.

Tot està tancat, els tècnics del clients entenen el que farem hi saben que ho podem fer bé. Han vist el tipus de feina que fem i s'ha generat aquella confiança que t'anima a col·laborar i a entendre el projecte com si fos teu. Però al darrer moment reb una telefonada: el meu cap ha decidit que ho farà algú que ell coneix. Deman per la tecnologia: punt net, amb asp, internet information server, Windows 2003 i Microsoft Sql 2008. Ni en els meus pitjors malsons recomanaria una tecnologia així pel projecte del client. A més jo li havia oferit un servidor dedicat, és el mínim per anar tranquils amb el tipus de dades que es tractaran i el tràfic previst.

Faig una ullada al mercat nacional de servidors. El fiera del Information Server els hi ha dit que molt millor un servidor nacional per millorar el posicionament. Obviament no ha tingut en compte que això és un factor de tercer ordre, i que si primer la plana no va prou ràpida i té prou ample de banda, ja no hi ha res a fer. De totes maneres faig una ullada al mercat nacional, a veure què hi ha amb aquestes configuracions. Vaig a parar a Arsys, que per 605 eur/mes t'ofereix una plataforma així pel`tot just 605 eur/mes amb llicència sql server express edition, si vols la "bona" són 350 €/mes.

Jo els estava oferint si també un servidor dedicat, amb el doble de prestacions que Arsys i també gestionat per nosaltres per 200 €/mes. Em diuen que la gent que els fa la web els hi han dit que el hosting serà de 60 eur/mes. Per aquest preu i a Espanya em temo que serà un hosting compartit, potser del proveïdor, amb el més nou de la versió patapalo-edition de Microsoft.

És una llàstima, la gent amb la que he tractat em cau molt bé i són els primers que no entenen la decisió. Sospit que pot ser un projecte molt problemàtic i que els acabarà costant sang i llàgrimes. Tant de bo no els costi l'empresa.

Segona conclusió Senyors directius, convindria que de tant en tant i en questions tècniques es fes cas als tècnics, que amb les coses de menjar no es juga.

Tercera conclusió Com el el cas anterior hi ha molt de risc de que el projecte fracassi i el client surti escaldat. Part de la responsabilitat és del client, que hauria de saber què compra, però també hi ha una gran responsabilitat del proveïdor, que està enganant al client.

Pero mira que som frikis

Aquesta setmana també m'han demanat un pressupost per a una connexió amb un servei web. Llegint la documentació veig que el WSDL (argh!) sols està certificat que funcioni (que és el mateix que dir que sols funcionarà) amb Java i .Net. Això se diu fer coses estàndard, sí senyor. És un servei complex i delicat, així que abans de pressupostar res convé fer un petit prototip. Li aplic suds, el client SOAP que feim servir habitualment per Python, i les sospites es confirmen, no és capaç de consumir el WSDL i transformar-lo amb Python. Odio els WSDL la S se suposa que és de Simple, no? Han conseguit fer un protocol infumable i que gairebé sols ho pot consumir la mateixa llibreria que l'ha creat.

Però bé, l'interessant de tenir una capça d'eines farcida és que hi ha alternatives. Feim un poc de brainstroming amb Juan. La primera opció és modificar el WSDL per a que el mapejador s'ho mengi, o bé anar donant ajudes a la llibreria. És una opció que no m'agrada, ja que si hi ha problemes el proveïdor del servei se'n rentarà les mans, fins i tot si la culpa és seva.

Una possibilitat seria fer el projecte an Java, però això significaria un cost molt més alt per al client, i sobretot una manca de flexibilitat a l'hora de fer modificacions, ja que el servei sols és una petita part del projecte. Python i Django ens permeten tenir un temps de resposta molt bo davant canvis i això és fonamental pel tipus d'aplicacions que fem.

L'altra possibilitat és fer un servei Java/J2EE que faci de proxy cap a l'aplicació Python. Amb un protocol de comunicació compartit com xml, json, yalm o un binari com el de Google la cosa pot funcionar. En Juan suggereix fer una ullada a jython, que ell li va fer una ullada i pintava molt bé. Li fem una ullada, el projecte està mantingut i és compatible amb Python 2.5, que ja ens va prou bé.

Fem el primer prototip. Cridam a la libria Java des de jython i fem la cridada al servei. Funciona a la primera. I això provant des de la consola de línia de comandaments de jython. Ja tenim part del problema arreglat, però encara no ens satisfà del tot. En nexe d'unió ha de ser net i jython, com aplicació Java que és necessita un temps considerable per iniciar-se.

Però vet aquí que Celery, el sisteme de coes de Python del qual ja us n'he parlat, resulta que soporta Jython. Podem crear el mapeig de la llibreria amb jython i fer que les peticions sian bé síncorones o asíncrones, però que s'executin com a una tasca Celery. Com que la petició es farà dins un worker i aquest està sempre aixecat, no tindrem problemes de temps d'inici una vegada pugi l'aplicació. Es monta el prototip amb Celery, Redis, Python i Jython, en Juan ho està disfrutant i jo també.

Ara puc fer el pressupost tranquil. Sé que el que podria representar el risc més gran ja no representa el problema, hem descober el boogeyman del projecte (l'home del sac) i l'hem exposat a la llum.

No sé si el projecte es farà, però tenc la conciència tranquila de que aquesta és la manera de fer les coses. A l'hora de fer un pressupost per a un client no es tracta sols de pegar una pedrada i a veure si hi ha sort, sinó en estudiar el projecte i veure'n els riscs que hi pugui haver. Per això sovint sóc un perepunyetes demanant informació abans de fer un pressupost. Sé perfectament que en aquesta fase tot pressupost té un marge d'error gran i que hi haurà variacions en el projecte, però crec que no és professional tirar-se a la piscina a l'hora de presentar un pressupost si hi ha un punt crític que no es té clar com es farà. Preferesc invertir uns dies de feina més (amb risc que el pressupost no surti i perdre la feina) que exposar-nos a nosaltres, al projecte i sobretot al client als maldecapts d'un projecte la viabilitat tècnica del qual no s'ha pensat a l'hora de fer el pressupost.

Ho deix aquí, que aìxò s'ha fet molt llarg. Em deixo parlar de coses igualment divertides, com la telefonia IP que estam posant a l'oficina amb Asterisk i el bé que se sent amb els mòbils Android, o la potència de Bacula per configurar les còpies de seguretat. Potser un altre dia ...

Aquesta setmana he estat força entretingut, m'he estat mirant un grapat de llibreries i utilitats, algunes d'elles noves versions que han anat evolucionant i millorant al llarg del temps. També vaig tenir l'oportunitat d'assistir a la xerrada de Maria Antònia Mas Pichaco damunt la guia PMBOK®, gràcies a l'empenta de Paco que em va recordar que es donava la xerrada. A part de la conferència en sí, també va estar molt bé el cafetó i la xerrada amb Paco, això de contar batalletes i compartir opinions no s'ha de perdre Paco! :)

Xerrada de PMBOK®

Si anam per ordre el primer seria parlar de la xerrada de Maria Antònia. A diferència d'altres assistents que l'havien tinguda com a professora, era la primera vegada que l'escoltava. Em va agradar, la exposició va ser clara i entretinguda. M'hauré de llegir la guia per poder-ne fer una avaluació en profunditat, però pel que vaig entendre es tracta d'un conjunt de recomanacions i millors pràctiques que cobreixen el cicle de la gestió de projectes, però que en cap cas ens marca un camí a seguir o una metodologia. Supòs que la utilitat vindrà quan ja hagis elegit com gestionar un projecte.

En la part anecdòtica me va fer gràcia quan un dels punts de la gestió del projecte consistia en "triar l'equip de gent". Em va recordar a aquelles pel·lícules on l'heroi va cercant l'equip en els llocs més inversemblants, sempre els millors en el que fan, per conformar un equip invencible. Bé, la realitat és que poques vegades tens ocasió de fer això, però quan pots és molt engrescador. El més normal és que l'equip et vengui donat i llavors el que s'ha de fer és tractar d'esbrinar quines mancances i quines aptituds té cada membre de l'equip per arribar a dur a terme el projecte. Seguint amb el símil fílmic, és mes semblant a les pel·lícules on l'entrenador agafa un equip que no coneix i el duu cap a la fita proposada (sempre amb final feliç).

Em va dur molts records una altra frase "un projecte ha de tenir una data de finalització", ja que és una discussió que havia tingut en algunes ocasions amb certa gent. Per mi un projecte comença, es desenvolupa i acaba, tal com també va dir Maria Antònia, tot el que no té dada de finalització entra dins la part d'operacions.

LibreOffice

Al portàtil de casa he substituït ja l'OpenOffice per LibreOffice, la migració va ser molt senzilla i per ara no he detectat cap problema. Pareix més ràpid i no dóna problemes amb el Firefox. No sé si me passa a mi sols, però amb l'OpenOffice i el Firefox en marxa les operacions de tallar i aferrar es feien eternes, ara això no passa. També he trobat millores curioses, com la possibilitat de tenir colors a les pipelles de les fulles de càlcul, opció que ja tenia el Quattro Pro de Borland i que el pas en massa de les empreses cap a Excel va deixar a l'oblit. Com a altra avantatja la millora a la pantalla de càrrega que li dóna un aire un poc més fresc i la millora en la navegació.

VirtualBox 4

He actualitzat el programa VirtualBox a la darrera versió, l'actualització des de la 3.2 és trivial i no s'han perdut màquines virtuals. El temps d'arrencada de l'aplicació i de les màquines virtuals ha millorat molt i també ho ha fet la interfície gràfica d'administració. A més ara té la possibilitat de connectar-se en remot a una màquina virtual mitjançant el protocol RDP, bé en sessió única o en multi sessió. Així dins una Ubuntu 10.10 tenia dues màquines virtuals, una Ubuntu 10.04 i un Windows XP (l'original que va venir amb el portàtil), aquest XP estava connectat via RDP a la màquina virtual Ubuntu i s'hi podi interactuar veient l'arrancada i tot. Des de l'altra ordinador, el PPC, també vaig connectar via remote desktop a la màquina virtual Ubuntu. Divertit i amb moltes possibilitats.

Sorl thumbnail

Sorl es una llibreria per a la gestió d'imatges per Django. És una reescriptura d'una versió anterior pràcticament des de zero. Incorpora totes les possibilitats de la versió anterior però ara de manera molt més transparent i entenidora. Han millorat com es fa caché de les imatges incorporant Redis com a opció de magatzem de claus, opció per distingir el tipus d'orientació de la imatges i un control per determinar si la imatges existeix o no (per exemple en remot quan dóna un 404) i actuar en conseqüència.

A les properes setmanes esper poder parlar de la sortida de Django 1.3 i de Celery. No sé què em fa més patxoca. Per una part Django 1.3 significarà que ja s'avança cap al 1.4, versió que està previst que incorporarà moltes més novetats que la 1.3 que és una versió més de correcció de petits errors i en general petites funcionalitats. Celery, la llibreries de cues per Python i Django també treurà aviat una nova versió. N'estic molt pendent ja que incorpora compressió de missatges, autoescalat, un nou protocol més eficient, ... Per ara m'he llegit la documentació i he de començar a preparar algunes de les nostres aplicacions que fan servir la llibreria migrant a l'actual Release Candidate i veure'n el camí de migració. Ja en xerrarem!

L'altra dia vaig tenir l'ocasió de parlar amb un responsable informàtic d'una empresa gran. Una conversa llarga però entretinguda, afegiria.

El cas és que en un moment de la conversa l'home va venir a dir que abans es pensava molt més a l'hora de programar, que com que el temps de CPU era molt més car, llavors els programadors s'havien de pensar molt el que feien, que els programes tenien menys errors d'entrada.

La veritat és que no tenc dades estadístiques de la quantitat d'errors que hi podria haver, però també és veritat és que pareix que la taxa d'errors per línia de codi és una constant que s'ha mantingut pràcticament constant al llarg del temps. De fet és una de les raons per elegir llenguatges d'alt nivell respecte a llenguatges de baix nivell a l'hora de programar, ja que hem d'escriure menys línies de codi, llavors la quantitat total d'errors introduït també serà menor.

Així doncs, tenir molt repensant els programes a l'hora de picar-los no feia que tinguessin menys errors, sinó que sintàcticament eren correctes. Però la gràcia dels analitzadors de codi actuals, dels compiladors, és que permeten caçar tots aquests errors de manera ràpida.

És a dir, actualment es pot teclejar el codi directament a l'editor, compilar-lo (o no si feis servir un llenguatge interpretat) i provar-lo en un cicle de realimentació ràpid. El que estam fent és aprofitar la tecnologia al nostre favor, deixar que l'ordinador caci els errors de sintaxi i ens avisi dels errors més obvis. En definitiva el que estam fent és aprofitar-nos de que l'hora de CPU té un preu al voltant de zero, superant en molt el cost de l'hora de programador.

Els programes s'han fet més complexos, amb més línies de codi, on cada vegada hi ha més capes i més distribució, i això fa que les tècniques de programació i testeig també hagin evolucionat. Encara tenim que picar el codi, però podem fer-ho directament a l'ordinador, no hem d'esperar per saber si el codi té errors de sintaxi o no, i això ens fa més productius i evita temps d'espera. Això no vol dir que els programador siguin ara més descuidats en el seu codi ara que abans, sinó que senzillament poden dedicar-se més ara a la funcionalitat i no tant a tenir que validar manualment que tota la sintaxi del programa sigui correcta.

Personalment no he tingut que tractar amb mainframes i amb el tipus de programació i feina de la que parlava el meu interlocutor, però tenc clar que en informàtica com en altres coses el temps passat no era millor. Potser ara el veim amb nostàlgia, però la realitat és que ara comptam amb una gran quantitat d'eines i ajudes a la programació que fan que el programador pugui destacar per la seva creativitat i coneixements i no per la seva habilitat mecanogràfica.

Avui tenia visita a Evissa per a tractar l'estat d'un projecte que tenim amb una empresa d'allà. Com que mai saps que te trobaràs per la carretera, tenc la mania de partir prest, la qual cosa em sol deixar una hora de mitja d'espera a l'aeroport. Avui més d'una hora i mitja, ja que no hi havia gens de coa a facturació.

Per passar el temps res millor que la lectura, en el meu cas un llibre que vaig rebre ahir: The Lazy project manager de Peter Taylor.

Sols puc dir una cosa d'aquest llibre: totalment recomanable. No és un llibre de metodologia de gestió de projectes, ni de bones pràctiques, ni d'aquells que et diuen el bé que els va sortir aquell macro projecte. És un llibre divertit, fresc, escrit amb un estil desenfadat, irònic i pràctic.

Taylor fa us del seu anecdotari personal per contar situacions que ha viscut com a cap de projecte. Conta coses que li han anat bé i també coses que li han anat malament. Focalitza molt bé el que ha de ser la feina d'un cap de projecte: gestionar l'equip, mantenir la calma davant els problemes i deixar que la gent faci la seva feina.

D'això Taylor en diu ser un Lazy manager, però no us malfieu. Ser un lazy manager duu molta feina. El títol fa referència a una actitud: intentar que les coses es facin amb el mínim esforç, concentrant-se en el que és important per al projecte.

Taylor duu el concepte a l'extrem, al primer capítol ja te diu: eps si vols anar al bessó del llibre ves al capítol de trucs ràpids. Però us aconsello que no ho faceu, us perdríeu una lectura molt divertida.

El llibre té 141 planes de lletra a doble espai amb la qual cosa es llegeix amb un parell d'hortes. Ideal per passar una bona estona a una sala d'espera, i per bona estona em refereixo a la rialla que se us pot marcar a la cara de tant en tant llegint els comentaris que fa Taylor.

Totalment recomanable sobretot per aquells que hagin tingut algun tipus de responsabilitat en la direcció de projectes, siguin informàtics o no.

Fitxa tècnica.
The lazy project manager
Peter Taylor
Ed infiniteideas
ISBN 978-1-906821-13-5

Avui precisament es complexien tres mesos des de que vaig deixar la meva antiga feina de cap de projecte web per TUI España (després a Hotelbes) per dedicar-me a un nou projecte: APSL.

És un bon moment doncs per reflexionar damunt el que suposa llançar-se a l'aventura en moments de crisi, sobre la constatació que les microempreses com nosaltres, tot i ser la gran majoria del teixit empresarial, ho tenen molt complicat pere accedir a ajudes i subvencions, però sobretot fer palesa la pau mental que et dóna fer el que t'agrada.

Potser el més detacable és la incorporació a l'empresa de Bernat Cabezas. Això vol dir que en pocs mesos hem duplicat el personal. També val a dir que això gairebé ha omplert el minidespatx. Dins l'aspecte de feina no ens podem queixar, van sortint projectes, amb comptagotes, però van sortint, i des del començament la nostra filosofia ha estat la de créixer quan ens ho poguem permetre, així que no estiram més el braç que la màniga.

Fer feina única i exclusivament amb Linux i programari lliure és molt productiu. No tenir que anar a reunions inútils i interminables ho és fins i tot més. Podem plantejar-nos solucions que a les nostres feines anteriors no seríen possibles: hem creat una solució damunt Amazon EC2 com a plà de contingència, fet screen scrapping amb Python i estam desenvolupant un petit motor de reserves de codi lliure amb Python per a hotels. I això fent el cafetet amb tranquilitat!.

Però no tot és color de rosa, la vida d'una microempresa és difícil. El primer de tot perquè has de començar des de zero. El que hagis pogut fer com a assalariat no compta. En parlàvem l'altra dia amb Juan de /IT que fa anys es trobàren amb la mateixa situació. Som les mateixes persones i amb les mateixes capacitats que quan estàvem assalariats, però hem de començar a crear portfolio i a demostrar el que sabem fer. No serveix el dir que en el nostre currículum hi ha la majoria d'aplicacions web internes i externes de TUI España, el que compta més és el que hem fet com a empresa independent.

El tema de les subvencions públiques també és una d'aquelles coses que t'indignem quan ets una microempresa. Darrerament hem intentat optar a un Plan Avanza per tal de poder accelerar el desenvolupament del motor web. La sorpresa va ser majúscula quan ens assabentaren que la inversió mínima per optar a una subvenció era de 200.000 €. Quantitat que com podreu veure queda molt lluny del que és una inversió raonable per a una organització com la nostra. Segons ens van explicar qui opta per aquestes subvencions, donat que són un 35% del pressupost, tenen tendència a inflar el pressupost i acaba essent un joc del gat i la rata entre que dóna la subvenció i que l'està sol·licitant. No puc entendre aquest joc, sols beneficia a qui té capacitat per poder inflar despeses i no a qui té capacitat per fer la feina.

Passa el mateix amb algunes organitzacions empresarials. Algunes estan organitzada a manera de capta subvencions i conformen un club exclusiu, on les quotes de participació serveixen per mantenir fora del club a les empreses més modestes.

Fa un poc de ràbia, però la veritat és que tant fa. Crec en que la feina ben feta al final donarà el seu fruit, i crec amb el creixement basat en l'esforç, en guanyar-nos els clients superant les seves espectatives. De la mateixa manera que entenc APSL com a un lloc on la gent tècnica s'hi pugui trobar bé, on a més de guanyar-se la vida s'ho passi bé fent feina. A un curs que vaig fer de l'EOI el director del curs em deia que això era una utopia, bé, potser sí, però m'agrada creure en que put trobar unicorn. I want a ponny diu la gent de Django.

Crec que els programadors, els tècnics i el frikis en general donam el millor de nosaltres mateixos quan ens deixen fer allò que sabem fer millor. Potser el temps demostrarà que jo estava equivocat, però al manco intentar fer que aquesta utopia sigui possible, i tant el client com el tècnic tenguin allò que volen i allò que necessiten és una aspiració que crec que s'ho paga com a projecte.

A l'aspecte personal, dir-vos que el meu nivell d'stress ha disminuït notablement. Sóc un passador de pena, no hi puc fer res, però al manco ara tenc la sensació de que hi puc fer alguna cosa. Que els problemes que sorgeixen al dia a dia no s'enquisten i els podem donar una solució. El que m'estressa més no és que hi hagi mota feina o problemes, això és la salsa de la feina, el que m'estressa és saber que s'hi pot posar remei i no poder-ho fer.

Arrib a casa amb la sensació de la feina feta, amb la sensació de que les hores dedicades a fer feina han servit per alguna cosa, encara que hi hagi dies on no tot surt com voldríem. És una sensació que feia molts mesos que no tenia.

He de dir que enyor molta gent de l'antiga feina. Hi vaig deixar molt bons professionals i millors persones, d'aquells que m'agradaria tenir amb nosaltres si el projecte APSL cresqués. Al Parc Bit també he retrobat antics companys de feina, molts ex-TUIS de la part de direcció i comercial que emigraren cap a projectes més engrescadors, antics companys de Viajes Iberia (gent us promet que quan no vaig tant de cul us faré una visita), companys Bulmeros i companys d'SMI.

Han estat tres mesos de mantenir contactes i crear ponts, no tant amb possibles clients com amb empreses i autònoms que tenen un tarannà semblant a nosaltres. Gent amb qui sé que podré comptar en un futur i gent que sap que pot comptar amb nosaltres.

Són temps difícils, de crisi, però també d'oportunitats. Vers la tudada de doblers que fan algunes institucions amb estudis d'estudis que estudien l'estudi, vers les subvencions atorgades a empreses que no les necessiten, potser les petites empreses com la nostra tenen la seva oportunitat. L'empresa privada s'ha de mirar molt bé on inverteix el seu capital, ha de cercar un rendiment als doblers i mirar molt la relació qualitat preu. Són temps on empreses com APSL poden tenir l'oportunitat. El temps ho dirà.

Aquesta setmana al grup de Django hi havia una interessant discussió damunt la idoneïtat de Django per una startup. Bàsicament la discussió girava entorn de la tecnologia, i de com si imposam una tecnologia al proveïdor aquest la posarà com a excusa si el projecte fracassa o no s'entrega a temps.

Per mi això vol dir una cosa: si hem d'encarregar quelcom a un proveïdor ens hem d'assegurar que farà el que toca. És a dir, si ja d'entrada et diu "nosaltres no feim feina amb la tecnologia xxx i ho faríem millor amb yyy" doncs la millor opció crec que és anar cap a un altre proveïdor.

Però el que m'ha agradat més ha estat una aportació que m'ha duit fins a un article de Kurt Grandis anomenat Python + Django vs. C# + ASP.NET: Productivity Showdown.

El vertaderament interessant de l'article de Grandis no és el resultat en sí. Demostra que a la seva empresa la productivitat del desenvolupament en Python i Django ha doblat la del desenvolupament en C# i ASP.NET, i és la demostració en sí el que fa interessant l'article.

No es tracta de que hagi llegit un white paper i ha vist la llum. Sinó que a partir del que coneix de la seva empresa ha posat en marxa un estudi sistemàtic per a provar si la seva hipòtesi de que l'augment de productivitat en Python era millor o no.

Salvant les distàncies, és més o manco el que ens va dur en els temps de TUI a canviar el desenvolupament des de Java+J2EE amb tot l' stack tecnològic de Tomcat, Spring, Hibernate i altres cap a Django i Python. Aleshores les necessitats de l'empresa eren la de poder crear aplicacions web en un temps molt curt, amb moltes adaptacions posteriors, aquest darrer requeriment per pròpia idiosincràsia del negoci.

Teníem les dades del que ens constava posar un projecte Java en producció en temps i esforç. Potser condicionat per la meva vessant de gairebé físic i m'agrada tenir dades experimentals o vet a saber per què, però m'agrada tenir constància de l'esforç que duen els projectes, així que vaig anar recopilant dades com temps, línies de codi, temps d'inici mínim d'un projecte, temps de desplegament, etc.

Els resultats a favor dels projectes fets en Python i Django eren aclaparadors. En el nostre cas l'equip de feina era igual de bo amb ambdues tecnologies. Així que poguérem comparar peres amb peres.

Vull dir amb això que l'elecció de la tecnologia i del llenguatge de desenvolupament és una cosa prou seriosa com per no fer-la a cop d'impuls. Convé mesurar i decidir en base als nostres propis estudis i conclusions. Que per nosaltres el factor de productivitat fos Python no vol dir que per una altra empresa ho sigui, potser pel tipus de desenvolupament que es fa els va millor fer feina amb Java, en PHP , ...

És important poder avaluar el projecte i l'empresa. Invertir temps i recursos en fer l'estudi. Avaluant productivitat, riscs i variables com el vendor lock, la motivació de l'equip i com no el retorn de la inversió.

Grandis ens conta com ho va fer ell i per això és un exemple tan valuós. Sovint ens trobam que darrera una decisió com la canviar de llenguatge de programació o tecnologia no hi ha res que la recolzi. Hem d'acostumar-nos a fer aquests tipus d'estudis si volem que la Informàtica comenci a tenir la consideració de es mereix.

La ponència va començar amb uns minuts de retard, la cortesia típica per a que la gent acabi d'arribar, minuts abans en Joan Barceló em va presentar a José Barato, d'Atos Consulting i férem un cafè, descafeinat, això sí, que els moments abans de parlar ja duc una bona embranzida com per apujar-la més amb la cafeïna.

A la sala poc menys de 60 persones. Algunes cares conegudes: Suki, JoanMi, Pau, Joan Carbonell, ... Potser hi ha més gent que conec, però en Joan Barceló ja m'està presentant i no tinc temps de fixar-m'hi massa. Paraules afalagadores de Joan, no sé si les meresc, però encara així són benvingudes.

He previst una exposició d'uns trenta minuts, més o manco a minut per transparència. Una altra vegada em record a mi mateix que he de trobar alguna mena de plugin o utilitat per a poder posar un crono a la pantalla que em vagi marcant el temps. Amb el mòbil al costat ja va bé per nar mirant l'hora de tant en tant i ara per ara això ha de bastar.

Vaig parlant un poc de filosofia de la gestió de projectes, de la importància de l'equip i de com les eines de codi obert ens poden acompanyar en tot el camí de la gestió de projectes. Sóc molt insistent en que l'eina no és l'important, que no és un fi en sí mateix, sinó que l'important és el projecte i la gent que l'ha de dur a terme.

Passa el temps i acab amb la presentació, en Suki veig que ha tuitejat l'inici i el final. Per això veig que he estat gairebé 37 minuts parlant. Se m'ha fet curt. M'encanta parlar d'aquests temes. Crec que fer pedagogia i ser insistent és la única via per a començar a canviar les coses. Que hi hagi una seixentena de persones a la sala, alguns amb resposabilitats de gestió de projectes potser ajudarà a que la gestió de projectes de programari canvii cap a una gestió on es dóni la importància a l'equip en el seu conjunt i es tengui en compte que el desenvolupament de programari no és com el que fa hamburgueses (m'agrada l'exemple de José Barato).

Després en Joan Barceló ens parla de OpenPPM, eina de gestió de carteres de projectes desenvolupada en codi obert i que està propera al seu alliberament. Ens parla de les eines utilitzades. Veig alguns comentaris en referència a la corbata i a que surt Word, Excel i Microsoft Project com a vies per donar-li de menjar a la bèstia. D'aquí dos temes a dir, per una part el tema de dur corbata o no, és quelcom personal, a mi no m'agrada, però tampoc m'agraden massa els vaqueros. Crec que la vestimenta no ha de condicionar la importància de les paraules i de les idees, encara que sóc conscient que sovint ho fa. De la utilització de formats tancats com a via d'entrada sí que crec que condiciona la llibertat del projecte, però en soc optimista. Fa un grapat d'anys tenir empreses com SM2 o Atos involucrades en un projecte lliure i parlant-ne obertament a unes ponències fora impensable. Està clar que encara hi ha coses a millorar, però el que no podem fer és voler-ho tenir tot de cop, s'ha d'anar fent camí. S'ha de reconèixer el que s'ha fet, l'esforç i la iniciativa i animar a seguir polint els detallets que queden per a poder considerar el producte vertaderament lliure.

La darrera conferència va ser la de José Barato, d'Atos Consulting. Pareix que José i jo hem llegit els mateixos tipus de llibres, ja que tant De Marco com Yourdon a DeathMarch formen part de les meves referències obligades. Jose va desgranar els principals conceptes que exposa De Marco i va explicar algunes anècdotes personals de Death March. Una de les anècdotes em va fer por: programadors coaccionats per fer feina sense anar a casa, dormint a la oficina. Segur que José Barato ja no ho fa això i n'ha après la lliçó, però segur que encara hi ha consultores que no han fet el canvi i aquests tipus de pràctiques poden ser fins i tot normals.

El cap de projecte té una obligació vers el projecte: la obligació de mirar de dur-lo endavant, però també té una obligació vers l'equip, la de no vendre'ls la moto. Embarcar un equip a una missió impossible sense el seu consentiment o dur-los més enllà del que humanament és possible fa malbé l'equip i el projecte.

En resum, unes xerrades entretingudes. Jo m'ho vaig passar molt bé i esper que la gent que hi va venir també trobàs coses interessants de la xerrada.

Gràcies a Suki per les fotografies.

El divendres vinent particip en la xerrada El lado humano del software, encara estic acabant de perfilar la xerrada, però com diu el títol parlaré de la gestió de projectes fent servir programari obert.

Tanmateix m'agrada el títol de la xerrada, ja que no vull parlar de com fer servir un o altre programa, sinó anar indicar quins problemes ens trobam en la gestió de projectes de programari i com hi ha programes de codi obert que resolen el problema, i ho fan des d'una vessant orientada a les persones i al grup de desenvolupament.

Pensant en la xerrada sorgeix un altre tema, què és el que fa un cap de projecte sigui un cap de projecte? La gent del PMIB vol anar cap a la professionalització d'aquesta activitat, però sé cert que molts ens conformaríem amb que l'accés a cap de projecte no fos una manera de cobrar més i deixar de programar, sinó una activitat on la gent que hi accedesqui en tengui vocació i formació.

No hi ha res dolent en que una persona que programa vulgui ser cap de projecte, particularment trob que un cap de projecte que ha estat un bon programador pot entendre millor les necessitats que té un equip de desenvolupament i connectar millor amb l'equip i el client. El que no m'agrada és que la gent que és bona programant i que ho vol seguir fent, si vol mantenir un nivell de sou tengui que anar cap a la direcció de projectes si no li agrada.

S'ha de valorar la feina de cap de projecte i s'ha de valorar la feina d'un bon programador, d'un bon tècnic de sistemes, ... La feina de cap de projecte no pot ser un objectiu per cobrar més, sinó una elecció raonada i no motivada sols per l'aspecte econòmic del lloc de feina.

El món està ple de caps de projectes de software de Microsoft Project i fulla de càlcul a una unitat compartida de Windows que han accedit a ser-ho perquè no els ha agradat mai programar (dubt si mai els ha agradat la feina informàtica) i no volen aprendre res nou. Crec que és això el que s'ha d'evitar, potser professionalitzant més l'ofici n'és una via, però un punt important és el d'anar fent pedagogia a les empreses de que no hi ha res dolent el pagar més a un bon programador o per un bon dba que a un mal cap de projecte.

A poc a poc però sense pausa estic embarcat en la creació d'un motor de reserves orientat cap a hotels i cadenes hoteleres. És a dir, no es tracta de fer un sistema genèric orientat a la integració d'xml com els que poden necessitar agències i TTOO, sinó de tenir quelcom flexible i ràpid de personalitzar orientat a cobrir les necessitats més o manco complexes de la venda directa on line de nits d'hotel.

És a dir, el sistema ha de cobrir el bàsic (gestió del nombre d'habitacions disponibles, tarifes, descomptes per ocupació, aturada de vendes, etc) però també ha de permetre cobrir necessitat que en aquests moments no coneixem. Per tant, tenir una bona bateria de tests que ens assegurin que afegint noves característiques no ens estam carregant les que ja hi ha és fonamental.

La idea del Test Driven Development és que s'han d'escriure els tests abans d'escriure el codi. Jo no sóc tan purista i els tests els escric quan els necessit, unes vegades abans i unes vegades després d'escriure el codi. La raó és molt senzilla, quan estic immers en l'escriptura de codi per a que passi un test, sovint me trob afegint noves característiques per les que no tenc cap test encara. Llavors crec que el millor és seguir a la zona de programació pura i dura i després escriure els tests. Crec que no és tan important el moment en el que s'escriuen els tests unitaris com el fet de tenir-los.

Un motor de reserves com el que descric es pot fer en qualsevol llenguatge, en el meu cas hem triat fer-ho amb Python i amb Django, ja que ens dóna molta flexibilitat posterior a l'hora de fer adaptacions, que és el que cercam. Així doncs la definició del model de dades i l'ORM que s'utilitza és el de Django, la qual cosa fa que sigui important poder testejar-ho amb les eines que ens proporciona aquest bastiment.

Llegint la documentació de Django podem veure que aquest fa servir els units test de tota la vida i que a més per a que els tests siguin realment unitaris el que fa es utilitzar una base de dades nova i neta cada vegada que executam un test, d'aquesta manera ens asseguram que no hi ha dependències entre diferents execucions de casos de prova i per tant que els tests són realment unitaris respecte a les dades.

Tot i que sigui una solució totalment vàlida, consider que eines com nose fan l'escriptura de tests unitaris una tasca molt més divertida, ja que no has de passar pena de com estructura els test, sinó simplement els has d'escriure amb unes convencions de codi (per exemple els tests han de començar o contenir la paraula test). Per mi això significa menys complicacions i poder reaprofitar petits troços de codi que tanmateix hauria necessitat escriure per provar l'aplicació sense tenir que donar-los el formalisme que necessita un unit test. L'ideal per mi és tenir nose integrat dins el sistema de test de Django.

Afortunadament més gent ha tingut aquesta idea i per sort per mi, gent amb un coneixement més profund que jo de nose a nivell intern com per fer-ne una adaptació per Django, us present el django-nose. És una aplicació que s'instal·la amb pip o easy_install i que necessita molt poca configuració, afegirem 'django_nose' al settings.py a la secció INSTALLED_APPS i afegirem TEST_RUNNER = 'django_nose.run_tests' per dir-li a Django que farem servir el nostre motor de tests enlloc dels seus.

La gràcia d'aquest mòdul i de nose és que és compatible amb el que ja hi havia, però a més afegeix molta més funcionalitat i agilitat a l'hora de crear els tests. Basta fer un python manage.py test --help per adonar-nos de tota la quantitat d'opcions que ens afegeix el mòdul a l'hora de testejar. D'aquestes m'agradaria destacar-ne algunes:

• --with-coverage Ens permet utilitzar la utilitat de coverage de Ned Batchelder que ens permetrà veure quines línies de codi no hem testejat encara. Amb opcions addicionals és capaç de generar-nos un html navegable per a que poguem veure exactament el context de les línies testejades i de les que queden sense provar.

• --processes Ens permet aprofitar els nuclis del nostre ordinador, els tests s'executen en paral·lel (recordau que els tests unitaris no han de tenir dependències entre ells) accelerant notablement el temps de procés.

• --with-xunit Fa que en lloc de tenir la sortida típica dels unit tests tenguen el format de xunit, el mateix que es fa servir als unit test de Java, per exemple, i que ens permetrà integrar els nostres unit tests amb eines d'integració contínua com Hudson.

A l'hora de testejar una aplicació com el motor de reserves és imprescindible partir de dades conegudes i controlades per poder determinar els resultats esperats. Per això la manera que té Django de carregar les dades és simple i elegant. A cada unit test i abans de l'execució de cada cas de prova es crea la base de dades (en el meu cas un sqlite3 en memòria) i es carreguen les dades inicials (o fixtures en la nomenclatura) que es defineixen a cada unit test. Els fitxtures no són més que arxius en format json, yaml o xml que representen els registres que hi ha d'haver dins la base de dades.

Per exemple: [{"pk": 1, "model": "sites.site", "fields": {"domain": "example.com", "name": "example.com"}} ]

Aquests arixus els podem crear nosaltres directament amb un editor com vim o bé aprofitar-nos de l'entorns de Django i crear-los a partir de l'admin. Així podem introduir les dades a la nostra base de dades i fer un

 ./manage.py dumpdata applicacio.model

per exemple:

 ./manage.py dumpdata sites.Site --indent=4

ens proporcionarà el codi json per al model Site, l'indent el que fa es proporcionar espaiat addicional per a que sigui més bo de llegir i de modificar.

Si ens va millor tractar amb yaml, és prou senzill canviar el format:

 python manage.py dumpdata sites.Site --format=yaml --indent=4

-   fields: {domain: example.com, name: example.com}
    model: sites.site
    pk: 1

Dins un mateix unit test podem carregar tants arixus de fixtures com vulguem, ja que basta definir una llista del que s'ha de carregar, això vol dir no tenir que tractar amb grans arixus de dades de proves, sinó poder-los fer molt més manejables i sobretot reaprofitables.

La combinació de fixtures, unit test de Python, eines de testeix de Django i nose és molt difícil de batre. Per una part tenim que escriure tests amb Python costa una fracció del temps i de codi respecte a escriure'ls en un altre llenguatge, però a més nose fa que la tasca sigui molt més natural i la capacitat de generar els fitxtures des del mananager de Django fa que una tasca avorrida es convertesqui en trivial.

Tenir una bona bateria de test és fonamental per provar l'aplicació, per demostrar que els casos que s'estan considerant funcionen i tenen les sortides que deim que han de tenir. Però la utilitat dels tests unitaris va més enllà. Són una eina imprescindible en la refactorització.

Una vegada l'aplicació ja fa el que volem arriba l'hora de plantejar-se si es pot fer millor, si l'aplicació pot ser més eficient, de refer el codi per a evitar repeticions. La regla fonamental de la refactorització és que no hem d'introduir funcionalitat nova, quan refactoritzam tot ha de funcionar com abans. Els tests unitaris ens ajuden a demostrar que la nostra refactorització és bona, en tant en quant passin exactament els mateixos tets que teníem abans de fer cap modificació.

Faceu Test Driven Development o agafeu una aproximació més pragmàtica, el cert és que tenir bons unit tests és una inversió de futur que costa sols un poc més de temps quan estam desenvolupant, ja que amb nose els tests es poden reaprofitar de les petites rutines per proves que tanmateix hauríem d'escriure. Els beneficis el veurem a mig i llarg plaç: quan refactoritzem, quan canviem codi, quan les proves les llanci un sistema d'integració contínua. És massa bo per a no fer-ho servir.

En Galigan l'altra dia es demanava pel Twitter com és que la gent que fa feina de manera independent no s'uneix per poder fer front a "consultoras dinosaurio".

Com que el Twitter és massa curt i massa immediat per poder poder dir les coses, doncs li vaig prometre un apunt al blog per contar com veia jo les coses. Potser amb aquest apunt tampoc aconseguiré explicar tot el que vull dir i el que pens del tema, però al manco serà un poc més desenvolupat que no un grapat de frases al Twitter.

Primer un poc de història.

La idea d'un conjunt de professionals autònoms que s'uneix baix una mateix marca no és nova a les illes. Fa temps i a partir d'un grup de gent que es coneixia de Bulma hi va haver un intent de fer tal cosa. Pel que jo sé (no hi vaig participar a l'experiment) la cosa no va acabar d'anar del tot bé.

Desconec exactament les raons del fracàs de l'experiment, però potser una d'elles va ser la inexperiència en unions com aquesta. En altres sectors com els missers i gestors per exemple, aquests tipus de col·laboracions són molt més habituals.

Tot i que no funcionàs la idea és prou bona. Va ser el punt de partida que ens motivà a formar APSL, no ja com a una marca sinó com a una societat limitada. La idea fonamental era, i és, unir a professionals amb una visió del que és el desenvolupament d'aplicacions web comú, professionals que es complementin i amb un objectiu comú.

L'experiment APSL

APSL té un nucli estable de gent des de el principi, que hi col·labora d'una manera o altre, uns són socis, d'altres just col·laboradors voluntaris (un bon exemple d'això són els #creant_bits). Però tothom amb una visió semblant de la informàtica i amb una cosa fonamental: confiança mútua.

Des de la seva formació APSL ha tingut com a objectiu la col·laboració entre professionals, però per a que tal cosa es produesqui aquesta col·laboració s'ha de donar de manera natural, ordenada i amb el consens de tothom. La confiança és a més el nexe que fa possible el projecte. Tothom que hi forma part ha de poder tenir la confiança plena de que cada un farà el que s'ha de fer en cada moment, que els egos no han de prevalèixer damunt l'objectiu més gran que és dur endavant un projecte empresarial a llarg termini.

La visió no és sols orientada a la informàtica, sinó també al model empresarial, a l'ètica empresarial, el que darrerament s'ha anomenat la responsabilitat social de l'empresa. Per a nosaltres això representa fer negocis d'una manera molt determinada, convertint-nos no sols en proveïdors dels nostres clients, sinó en col·laboradors, en una relació quasi simbiòtica on tothom hi ha de sortir guanyant. En poques paraules, no es tracta de donar el pelotazo sinó de mantenir una relació de confiança i col·laboració que s'estengui al llarg del temps.

Supòs que tot això us sonarà a la gent que heu parlat amb mi i com molts us adonareu no és una cosa massa habitual en el nostre sector (sobretot fora del programari lliure), per això dic que APSL és un experiment, perquè trob s'ho paga intentar que un projecte així tiri endavant.

Per què empresa?

L'empresa és el nexe d'unió. Representa una manera formal de fer les coses i estableix unes regles de joc comercials i mercantils. Implica que hi ha un admintrador/gerent que dóna la cara, que pot coordinar els distints projectes i saber què fa tothom.

I per mi això és el que marca la diferència entre projectes semblants que s'estructurin al voltant d'una marca i dels que s'estructuren al voltant d'una empresa: la figura de l'administrador, de la persona que ha de vetlar per a que l'empresa funcioni com a tal, encara que internament els seus membres siguin tots professionals.

L'empresa com a tal dona recolzament als professionals que la formen. Fa que el tot sigui major que la suma de les parts, i a la seva vegada imposa tota una sèrie d'obligacions: facturació comuna, comptabilitat clara, despeses comunes, ...

Des del moment que es té un lloc comú de reunió, que s'ha de pagar, una facturació i uns comptes que s'han de presentar, la col·laboració passa de ser una cosa esporàdica entre professionals i convertir-se en un tirar del carro comú. S'han de tenir millors serveis compartits, aquella lasser que fa falta, el servidor que s'ha d'ampliar i gestionar, els clients que s'han de visitar, ...

APSL està pensada per créixer de manera orgànica i pausada en vers l'objectiu d'agrupar professionals, de sumar talent i proporcionar serveis comuns que d'altra manera no es podrien tenir, d'arribar a projectes que amb un altre tipus d'estructura serien directament inabastables.

Però tot això ja us dic que té tota una sèrie d'implicacions que s'han de conèixer i que potser en altres intents d'aquest tipus no s'han donat tant. Deixau-me canviar un poc de registre i no referir-me tant a APSL sinó a com ho veig en general.

Què implica un projecte de col·laboració?

• Objectius comuns. Ja no es cosa d'anar cada un pel seu compte i que l'empresa sols es tengui en compte a l'hora de presentar-se a un projecte, sinó que s'ha de tenir l'objectiu de fer que l'empresa com a tal cresqui. Els projectes ja no són propis sinó que són de l'empresa, de la mateixa manera que ho són les despeses.

• Confiança professional Tothom ha de poder confiar amb tothom i els clients han de poder confiar en els professionals de l'empresa. La visió de l'empresa i del model de negoci ha de ser la mateixa per tot els professionals agrupats entorn a l'empresa.

• Complementarietat En un negoci global com és la informàtica els professionals que s'agrupin en un projecte de col·laboració han de ser complementaris i no tan sols en l'aspecte tècnic (que també) sinó en l'aspecte fin i tot de caràcter. No tot és programar, també s'ha d'anar a captar clients, fer pressupots, parlar amb gestors, dissenyar l'aplicació, documentar, fer fotografies, ...

• Serveis compartits Un altre dels nexes del projecte ho han de representar els serveis compartis: el local, els servidors, la infraestructura posada a disposició del integrants del projecte. El local, per exemple, fa que hi pugui haver un punt de feina on la gent que es sent més còmoda fent feina fora de casa hi pugui anar. S'ha de pensar a llarg plaç i reservar capital per a invertir en el projecte: millor mobiliari, local amb més possibilitats, millors servidors, possibilitat de organitzar cursets, d'anar a conferències.

• Despeses S'ha de ser conscient que un projecte de col·laboració a llarg plaç té despeses. La feina d'organització i gestió interna pot arribar a ser força important quan es tracta de gestionar un projecte on un gran nombre de professionals han de de col·laborarar, s'ha de mantenir per una estructura gran un nivell d'abstracció semblant al que es tenia com a professional, però aprofitant les sinèrgies que implica col·laborar amb altra gent. Això vol dir que els beneficis de la nostra feina com a professionals ja no són sols nostres, sinó que són de l'empresa i dels altres col·laboradors. Joel Spolsky tracta molt bé el tema a The Development Abstraction Layer. Fitxau-vos que les despeses no es refereixen al material, a la llum o al local, sinó a tot el necessari per mantenir el nivell d'abstracció que permeti aprofitar les sinergies que impliquen posar feina en comú.

• Creixement orgànic Personalment pens que s'ha de ser caut a l'hora de créixer. S'han de cercar les col·laboracions permanents quan la gent ja es coneix i ha fet feina junta en alguns projectes. A l'hora d'admetre nous membres aquesta admisió no ha de ser fruit de la necessitat sinó de l'acord de tots els membres. Ja no estam sols, som un equip, una empresa i per tant la decisió de amb qui es col·labora i amb qui no ha de ser quelcom comú.

• Suport mutu Quan un fa feina sols qualsevol problema o incidència personal té un impacte brutal damunt la seva activitat. Per una empresària el naixement d'un fill pot representar tant una alegria com a un risc. Col·laborar implica estar a les dures i a les madures, minimitzar els impactes que puguin tenir els membres. Ara es funciona com a empresa i com a tal els projectes i els clients són comuns. Implica estar dispost a conèixer els clients i els projectes de l'altra gent, ser-ne el backup en cas que fos necessari, i si més no sempre tenir-ho previst.

Així és com jo ho veig, i és el que estam intentant dur a terme amb APSL. Personalment crec que qualsevol projecte de col·laboració que es presenti just en termes mercantilistes i d'oportunitat té poc futur. S'han de tenir en compte més coses. Tot i que es vulgui mantenir la llibertat de moviments que implica ser un professional autònom s'han d'establir unes regles de joc i s'han d'assumir tant beneficis com obligacions.

Aquesta setmana passada vaig llegir la tèsi de Rory Tulk "Software Testing Techniques, an Empirical Approach" de l'Universitat de Toronto (una vegada més gràcies a Jordi Cabot per publicar l'enllaç). La tesi es pot trobar via la plana de Rory o bé descarregàr-se-la directament.

Rory investiga damunt les capacitat de testeig segons el grau de maduresa tècnica de qui fa el testeig. La hipòtesi és que els tècnics més experimentats són millors testejadors que els juniors. És un treball que s'ho paga llegir per la pròpia estructura de la tesi i veure com s'ha conduit l'experiment.

Però el que més m'interessa del tema són les conclusions: l'experiència no té massa a veure amb el nombre d'errors trobats però sí que pareix que té a veure amb els tipus d'errors que es troben. Encara que el nombre de casos estudiats fa que les conclusions no siguin estadísticament significatives, sí que entronca en les pràctiques més o manco habituals de fer que sigui una persona diferent de la implicada en el projecte de desenvolupament la que provi els programes, ja que sovint descobreix errors que s'han passat per alt als desenvolupadors, que en teoria són més experimentats trobant-los.

D'aquí una possible conclusió seria que els equips de testeig i qualitat han d'estar formats tant per gent senior com per gent menys experimentada, de manera que es puguin complementar mútuament. Això vol dir, però que hi ha d'haver una rotació en els equips de testeig, ja que en cas contrari així con els juniors es vagin convertint en programadors experimentats tendran tendència a trobar uns tipus d'errors concrets, i no provar coses que d'altra manera, sense els condicionants de l'experiència provarien.

L'altra conclusió marginal interessant és el bon funcionament de la lectura del codi com a eina per a la detecció d'errors. Segons Karl E. Wiegers autor de Peer Reviews in Software un lector experimentat de codi pot arribar a caçar fins al 90% d'errors en el codi. Dins l'estudi de Rory precisament qui té la taxa de detecció d'errors més grans és una persona que va fer servir el mètode de llegir el codi per a detectar els errors.

Una lectura interessant i que convida a reflexionar, ja que comença a donar una base per a estudis posteriors. El testeig no és, com moltes branques del desenvolupament, una ciència exacta, però el que pareix clar és que els equips de testejadors han de ser diversos en la seva manera de veure les coses i que no basta una manera de testejar. I tot i això segur que quedaran errors sense caçar, per saber més o manco quants ja sols ens queda anar cap a mètriques estadístiques com les corbes S o les corbes de Rayleigh. El Software Mesasurement and Estimation de Lida M. Laird an Carol Brennan ten té un bon grapat de mètodes estadístics.

Com a conclusió addicional: convé registrar els tests que es fan, els errors que es detecten i estudiar-los, no com a via per a premiar els testejadors (el típic de condicionar un pagament d'objectius) o de penalitzar els desenvolupadors, sinó com a manera d'estudiar estadísticament els tipus d'errors que s'estan trobant i poder saber quan convé renovar par de l'equip de testeig. L'estar en un equip de testeig per exemple podria ser part de la carrera professional d'un programador.

Un link passat per Jordi Cabot al Twitter anomenat Asshole driven development em fa recordar el complexe que és la interacció humana en la gestió de projectes.

Quan més gran és una empresa més possibilitats hi ha de veure's reflexat en una de les definicions que fa Scott Berkun, més que res per una qüestió de probabilitats. Personalment m'he trobat molt amb el Cover Your Ass Engineering (CYAE) ja que és el típic que es presenta quan enfrontes una solució de codi obert amb una solució propietària a un gestor més preocupat pel seu lloc de feina i cobrir-se les esquenes si hi ha el mínim risc, que per les possibilitats de benefici real de l'empresa.

L'_Asshole Driven development (ADD)_ realment m'ho he trobat poques vegades, més que res perquè quan m'he trobat en situacions on els tirs anaven cap aquí he preferit anar cap a opcions alternatives. Ja sabeu que em costa molt combregar amb rodes de molí, i l'ADD és precisament això: fer les coses no perquè són tècnicament correctes o millors per l'empresa, sinó perquè qui mana (que no és normalment l'amo de l'empresa) diu que s'ha de fer ell que ell diu i punt.

El que sí m'he troba sovint són dos estils d'entendre la gestió de projectes i la pròpia feina del cap de projecte. M'explicaré:

Per mi l'objectiu d'un projecte informàtic és sempre aportar valor a l'empresa. És a dir hi ha d'haver un benefici mesurable en el projecte, ja sigui benefici en imatge, en menor temps de feina intern per fer les coses, en un major control o el millor de tot, un benefici real en termes de negoci.

Partint d'aquesta base entenc la feina d'un cap de projecte de desenvolupament com el d'aquella persona que s'ha d'encarregar de coordinar la feina, relacionar-se amb el client i sobre tot, de prendre decisions. L'important és estar focalitzat en que la feina surti i representi un benefici pel client i per això el cap de projecte ha d'eliminar els obstacles que es presentin per tal que la gent que fa feina en el projecte pugui fer la feina que millor sap fer.

Això vol dir no convocar a reunions multitudinàries als membres de l'equip quan aquestes no aporten res. És encarregar-se d'anar a parlar amb altres departaments, amb el negoci, dur el control administratiu del projecte, fer el reporting. És a dir, totes aquelles coses que formen part de la cerimònia del projecte i que mal duites poden impedir als membres "productius" fer la seva feina.

Amb aquesta filosofia entenc que el cap de projecte ha de posar tots els recursos a la seva disposició per dur bon terme el projecte. Si el programador té problemes amb una rutina o amb el llenguatge ha de mirar de solucionar-los, bé ell mateix o cercant algú que ho pugui fer. Alguna vegada m'han dit que donar suport als programadors no és la meva feina i n'estic en total desacord. La feina d'un cap de projecte és precisament aqueixa: donar suport, i si aquest suport significa resoldre un dubte de programació, depurar en conjunt un algorisme on algú s'ha quedat enrocat, s'ha de fer si es tenen els coneixements i l'oportunitat. Perquè per damunt de tot el cap de projecte està per eliminar obstacles i donar solucions. Si un projecte ha de sortir i no puc ajudar més que en dur els cafès doncs millor llevar-se d'enmig i demanar a la gent pel sucre que vol i si els vols sols o tallats.

L'altra estil de gestió és òbviament el contrari: reunions per pressionar la gent, reunions per repartir culpes i concentració del cap de projecte en la cerimònia, és a dir, gestionar concentrant-se amb el com i no amb l'objectiu final.

Perquè està clar que tot projecte pot fallar, per les causes que siguin. Però quan falla l'excusa no pot ser anar cap a un Cover Your Ass Engineering (CYAE) i establir mecanismes burocràtics i de control absurds per a que no tornin passar les coses, sinó cercar la causa de base del problema i solucionar-la de manera que afecti de manera mínima a la cerimònia del procés.

Si un programa falla perquè no s'ha pogut provar, la solució no és tenir que redactar un document a casa passi a producció on l'equip de programadors certifica que està bé, el testejador certifica que ha provat l'aplicació i el tècnic certifiqui que ha passat el pegat que li han dit; sinó demanar-se perquè no hi ha tests unitaris, perquè no hi ha (o han fallat) les integracions contínues. Potser el que ha fallat és que la gent no té prou formació per a realitzar bons tests. Massa cerimònia mata la creativitat i far perdre l'objectiu del projecte, formar a la gent fa millors professionals.

Tot són estils de gestió, jo sé el que m'agrada i intent posar en pràctica, adaptant l'estil de gestió al client, al projecte i a l'equip. Els programadors no són els curritos del cap de projecte de torn, és el cap de projecte el qui ha de fer feia pels tècnics i programadors i procurar que ells puguin fer la seva feina.

Avui he acabat de llegir The Medici Effect, un llibre que em va recomanar fa unes setmanes Greg Garrison, un de les persones amb més idees que m'he trobat fa temps.

The Medici Effect tracta de la innovació, dels camins que duen a les noves idees. De com la mescla de conceptes, experiències i gent dóna lloc a noves idees, a nous productes que trenquen amb tot el que hi havia fins al moment. Es creen nous negocis, nous camps d'investigació, noves empreses no de manera evolutiva sinó disruptiva, fruit d'una combinació de factors i de gent.

El llibre tracta de com poder conseguir aquest factor disruptiu, de com trobar el Frans Johansson, l'autor, anomena la intersecció. El punt de trobada on les corrents i les idees es mesclen i donen lloc a una cosa nova.

Johansson ens mostra amb exemples com distintes persones i empreses són conscients d'aquests tipus de combinacions i de com els cerquen activament en els seus negocis.

El llibre és prou interessant, motivador fins i tot. Alguns dels consells que dóna són prou bons. Tot i això les idees que presenta es poden resumir en pocs conceptes:

• Cerca la intersecció.
• Reconeix la innovació
• Assumeix el canvi i no tenguis por a trencar barreres i xarxes socials.
• Assumeix el risc

Amb això vull dir que és un llibre que es podria haver estalviat un 50% de les 190 planes de text. Sovint es fa repetitiu ens alguns exemples i es perd un poc per les bardisses a l'hora de focalitzar el tema.

En resum, un llibre interessant, que convé llegir, especialment si ja us heu convençut de que la innovació és una bona cosa, sou capaços de generar idees o simplement voleu una visió de com altres gestionen projectes i idees que canvien el món.

Fitxa Tècnica
The Medici Effect
Frans Johansson
Harvard Business Scholl Press
ISBN-13: 978-1-59139-186-9

L'autisme es caracteritza per una escassa interacció social, problemes en la comunicació verbal i no verbal, activitats i interessos greument limitats, inusuals i repetitiu. Viquipèdia

Aplicat a l'activitat laborar podem parlar de l'oficina autista, aquell entorn de treball en que les condicions ambientals, d'organització i de feina fan que la gent es retragui en ella mateix, minimitzant la comunicació i la interacció a nivells mínims, interessant-se sols pel que passa pel seu redol i intentant frenar i minimitzar qualsevol tipus de canvi.

Un dels símptomes de l'oficina autista és entrar i veure que molta gent té els auriculars posats i es sent el remor de la música sonant a les seves orelles. Això i un entorn renouer i amb una densitat de gent molt gran.

De Marco a Peopleware ja tracta el problema de la densitat de gent i la productivitat. Encara que una persona pugui fer feina en un espai reduït, posar molta gent mantenint la proporció d'espai fa que el renou i la sensació d'agobi augmentin. Suposem que una persona necessita 5 m² per fer feina, no és el mateix tenir 4 persones a un despatx de 20 m² que tenir 40 persones a una oficina de 200 m², la quantitat d'interaccions, renous, gent anant amunt i avalls, ... La productivitat es ressent.

Els tècnics però som gent que ens agrada fer feina i que la feina surti. De Marco diu que en aquests casos la gent intentarà fer feina de la millor manera que pugui, escapant-se a sales de reunions i a altres espais menys problemàtics. Avui en dia tenim tota casta d'aparells electrònics que ens permeten aïllar-nos d'un entorn poc apte per a la feina.

Aquest aïllament, però, té un problema fonamental, l'oficina es converteix amb una oficina autista. La gent no participa del que es cou ni tant sols amb el seu grup de treball. Els comentaris i la comunicació informal no existeixen. Per comunicar amb la gent del mateix equip i que està a pocs metres es necessari l'enviament d'e-mails i convocar reunions. La productivitat decau, es perd la sensació d'equip i de grup.

Potser algú ara dirà que ell es posa els cascs perquè fa feina millor amb música. Això no hi té res a veure, encara que trobem estudis que diguin que això no és veritat en tasques que requereixen molta concentració també segurament en trobarem que diuen tot el contrari. Aquests tipus d'estudis poden estar desviats per mor del que s'anomena Efecte Hawthorne. El fet però, que fins i tot en els casos de que hi pugui haver un petit augment de la productivitat personal, es perd la productivitat del grup, que és molt més important.

Si l'oficina és autista és quelcom que s'ha de millorar. Si no ho és hem de procurar que no s'hi convertesqui (sobretot si no hi ha factors ambientals associats). La comunicació ha de ser fluïda, les comunicacions formals s'han de deixar per coses formals. Si volem gaudir de la productivitat i eficiència que dóna fer feina amb grup hem de crear els factors ambientals que la facin possible. Si els factors ambientals són bons, no hi ha excusa per a deixar que l'aïllament autoimposat impedeixin una comunicació eficaç.

Ahir en Jordi Cabot em demanava l'opinió per Twitter dels IDEs, ja que hi ha gent que vol fer el que s'anomena web modeling tools, és a dir, passar les eines de modelat a un entorn Web.

Jordi no n'està massa convençut de la idea, ja que per exemple, els IDEs de programació per web no pareix que tenguin tirada, i fins i tot molta utilitat en aquests moments.

Particularment els llenguatges de modelat com l'UML m'agraden com a eina comú per a comunicar idees i no com a una eina per a la generació d'aplicacions completes. Veig utilitat a les eines de modelat web quan hom tengui entorns dispersos i col·labortius, on aquestes eines, amb un llenguatge simbòlic comú, serveixin per a definir i comunicar conceptes i tasques. Això no seria més que una pissara col·laborativa potenciada amb eines per fer més fàcil el dibuix. Ja està prou bé tot i així.

Actualment hi ha un grapat d'eines web per a la construcció de wireframes, interfícies d'usuari on l'important no és el disseny final, sinó la col·locació de cada component i la idea general de la interfície. Aquestes aplicacions son prou sofisticades, però no tenen massa a oferir respecte aplicacions com Pencil si no és per seva manca d'instal·lació i el tenir els dissenys a la web. Manca però el que es pugui fer un disseny realment col·laboratiu, on tothom pugui aportar idees damunt el mateix disseny, que és el que afegiria vertader valor a aquest tipus d'eines.

En el cas dels IDEs no es tracta sols de comunicar, es tracta de codi que s'ha d'escriure. Encara que es pot argumentar que un programador es passa més temps pensant i depurant que escrivint codi, el cert és que tenir un bon editor és fonamental. Per mi aquí el que és fonamental és tenir control del codi i poder treure el màxim suc de l'editor i de l'entorn.

Amb això vull dir que per defecte defuig de llenguatges de programació que m'imposen un editor o un IDE concret i que no s'integren amb un control de versions obert com subversion (com a mínim). L'IDE no importa, és que importa és el codi i el llenguatge i les restriccions que aquest imposa a l'hora de desenvolupar.

Els IDEs tenen de bo que ens donen la feina de triar les eines feta: editor, depurador, control de versions, tot ben integrat si hi ha sort, de tal manera que no fa falta canviar de programa per fer les tasques més habituals i això representa una bona ajuda per aquells que s'atraquen per primera vegada a un llenguatge de programació. També es força habitual que els IDEs editors molt potents, amb autocompletat, gestió d'arxius, cerques avançades, etc. És a dir, ajudes a la productivitat que ens poden anar molt bé.

Però hem de ser conscients que tot això té un preu: els IDEs són feixucs, consumeixen molts recursos de màquina i poden no donar-nos totes les característiques que volem: el depurador pot ser massa simple o no funcionar, estar limitats a un llenguatge de programació, no ser compatibles amb el nostre control de versions...

Aquests tipus de limitacions segurament no la trobarem a editors com Vim, o Emacs o semblants, ja que es limiten a les tasques d'edició i miren d'arribar al nombre més gran de llenguatges possible. Les eines de depuració o control de versions queden fora, se n'han de fer servir d'externes. Això no representa massa problema per gent acostumada a fer feina en entorns Unix, però sols representar un entrebanc important per la gent que sols fa feina amb Windows i en que anar a la consola pot representar un vertader trauma.

Particularment m'agraden els IDEs i els faig servir més o menys en funció del llenguatge i del programa que estic fent. Per a escriure Python faig servir Netbeans o Ulipad darrerament, per Java fonamentalment Eclipse, perquè m'agraden les ajudes que tenen, fent-me la vida més fàcil. Però tot i agradar-me procur no dependre'n i moltes vegades acab amb el vim com a editor, encara que sigui sols per mantenir el múscul actiu.

El que no m'agraden són els IDEs de programació que t'amaguen el que hi ha per davall, que no et deixen anar al codi o que es guarden el codi (como el PL/Forms d'Oracle). Però fixau-vos que no és culpa dels IDEs, és per pròpia construcció del llenguatge de programació, l'eina és sols un reflex del que hi ha per davall.

Per mi no és tan important l'eina que es faci servir per editar el codi com que aquesta no vulgui tenir el monopoli del codi editat. El codi ha de poder modificar-se independentment de l'editor, ha de poder posar-se en un control de versions, hem de poder saber els canvis que se n'han fet.

Les eines gràfiques de generació de codi (que alguns venen com a els nous IDEs) ens amaguen el codi, la visualització del que fan és molt complexe quan les tasques a realitzar van més alla dels exemples bàsic i fan molt difícil saber què s'ha canviat i a on, i el treball en equip es coordina bloquejant la tasca dels altres. Aquests IDEs no m'agraden. Poden significar un augment de productivitat inicial, però no escalen bé en programadors i representen una hipoteca tecnològica (i sovint pecuniària) de la qual n'hem de ser ben conscients.

Com a programador estic sempre a la recerca de l'eina perfecte, que em permeti desenvolupar programés més ràpid i ser més productiu, però hi ha coses a les que no puc renunciar: al control del codi, al control de versions i sobretot a poder canviar d'eina quan jo vulgui.

Avui m'agradaria parlar de dues eines que crec que ens poden ajudar molt en la tasca de comunicar-nos amb el nostre client a l'hora de definir un projecte: pencil i shutter.

Pencil és una eina que s'instal·la com a un plugin de Firefox (encara que es pot executar de manera independent) i que serveix per fer diagrames orientats a interfícies d'usuari. Ha evolucionat molt darrerament i ens permet crear prototips prou rics en widgets, tant per a definir interfícies d'escriptori com per a definir interfícies web. En la versió 1.1-rc2 que és la que he estat provant, ens permet crear documents multiplana, crear els nostres propis components, té un visor d'imatges que enllaça amb openclipart i ens permet exportar el disseny creat a a html, pdf o odt.

Shutter és un capturador de pantalla avançat, el millor que he vist fins ara per Linux. Ens permet capturar la pantalla, una finestra, un troç de finestra i modificar mínimament la imatge aplicant-li efectes o afegint-hi text. És a dir, té tot el necessari per a convertir-se en una eina imprescindible a l'hora de fer manuals o documentació que impliquin afegir imatges d'un programa.

Per mi aquestes eines tenen un gran valor. Pencil permet definir l'estructura bàsica d'una aplicació sense perdre massa temps i sense entrar en el disseny final. És a dir, ens permet avançar en el què ha de fer l'aplicació en lloc d'enrocar-nos en l'aparença de la mateixa. Això és molt important en les etapes inicials dels projectes, pensau que molta gent no sap el que vol, i encara que sàpiga el que vol teniu en compte que la feina d'un cap de projecte no és tant donar al client el que vol sinó donar al client allò que necessita. Tenir eines que ens permetin comunicar a alt nivell per a poder esbrinar què és allò que es vol ver és força important. Aquestes eines per la seva banda han de ser tals que no ens dugui massa feina ni esforç crear els dissenys, ja que per una banda el projecte encara no sabem si es farà i per altra se suposa que hi haurà força canvis, així que les iteracions entre les xerrades amb el client i els canvis que es puguin fer han de ser molt ràpides. Pencil trob que comença a tenir una bona relació entre capacitat de comunicació i velocitat a l'hora de fer els canvis.

La veritat és que els wireframes en aquestes etapes es podrien fer perfectament amb llàpis i paper. Hi ha autors que recomanen que sigui així. Això però quan es posa en un pressupost o dins una presentació no té l'impacte visual necessari per a donar una imatge de qualitat al projecte, i per tant que en lloc d'eines com Pencil es pugui fer servir paper i llapis de colors i un escanner depèn més de l'audiència a qui va destinada la presentació o el pressupost que el que sigui possible fer-ho d'una maner o altre.

Eines com Shutter i Pencil ens donen la capacitat de fer bons pressuposts, tutorial; concentrant-nos en el que es vol dir i donar la referència visual. Són un estalvi de temps i donen lloc a un augment de les nostres capacitats de comunicació, en el que volem dir sense que el temps per posar-ho elegant sigui un impediment.

El 2009 ja gairebé s'ha acabat, així que com és habitual convé fer un poc de recapitulació del que ha estat l'any 2009 i definir el que esper del 2010.

Trespams

Sense haver acabat l'any aquest és l'apunt que fa 77, això vol dir que ha estat un any prou constant en el que és la publicació d'apunts en el blog, . M'agrada escriure, em relaxa i em permet posar idees en clar. Si a més aquests posts serveixen a algú més, encara que sols sigui per passar l'estona, crec que s'ho paga el petit esforç de posar-se davant l'ordinador i teclejar.

En aquest moments Trespams té uns 900 visitants més o manco habituals. D'aquest n'he pogut desvirtualtitzar un tant per cent molt petit, potser un 10%, alguns han deixat comentaris i hem pogut mantenir converses virtuals tant pel blog, correu o Twitter. Per mi és una de les experiències més gratificants del blog: poder compartir idees i pensaments amb comunicació bidireccional.

Des del principi el blog ha estat per mi essencial a l'hora de posar en ordre les meves idees i dèries. La gestió de projectes, la gestió d'equips de programació, l'estimació de projectes de programari, Python i Django. Tot sempre amb un fil conductor comú: el programari lliure.

El blog vol ser també part de la meva petita aportació al moviment del programari lliure. Programari lliure per mi significa no sols compartir codi, sinó compartir idees de com podem crear i gestionar aquest codi, eines, idees, ... El coneixement ha de fluir per a que tots com a societat ens en puguem beneficiar.

Python i Django

Per Python i Django també ha estat un bon any. Ha sortit l'esperada versió 3 de Python i Django ha assolit una velocitat de creuer que el consolida com un dels bastiments de referència en la programació web moderna. La llista de Django té uns 15.000 subscriptors, al repositori de projectes de Python, PyPi hi ha una cinquantena de projectes i actualitzacions de projectes diàriament.

Esper que el 2010 torni a ser un any Python, projectes com PyPy i Unladen Swallow poden donar encara més empenta a aquest fantàstic llenguatge. Esperem que l'onada Python arribi també a les empreses per a que tots ens puguem gaudir d'una programació més clara, mantenible i sobretot divertida, on el llenguatge no sigui un condicionant sinó un vehicle per a la creació de programes i la generació de valor per al negoci i en definitiva per a la societat.

Pel 2010 l'objectiu és anar creant més exemples a Appfusedjango, millorar-ne la documentació amb Sphinx. Voldria també millorar el codi d'aquest blog, fer-lo més accessible als dispositius mòbils. M'agradaria poder fer aportacions al projecte Basie, un projecte amb el qual he pogut coneixer noves formes de col·laboració, de control del codi, d'eines, nova gent.

Tot això farcit d'apunts en aquest blog, com a manera de presentar el que m'agrada, d'animar a la gent a participar, i com ja he dit, com a manera d'ordenar les meves pròpies idees. Es presenta doncs un any 2010 força interessant.

Creant Bits

Creant bits és la demostració del que es pot fer quan les idees es converteixen en accions. Un petit comentari al Twitter i la col·laboració de molta gent va fer possible que una vintena de persones ens trobàssim al Parc Bit per parlar de tecnologia, de Python i de Django.

La meva intenció és repetir-ho al llarg del 2010 i més si tenim disponibilitat de Sala. En aquests moments i baix el paraigües d'APSL tenim accés a les sales de formació del Parc Bit i convé aprofitar-ho. Quan no hi tenguem accés ja veurem que feim, però m'agradaria que fos quelcom que anàs perdurant en el temps fins que el cos aguanti i la gent no es cansi.

L'altra dia per un comentari que vaig fer al Twitter d'un curs de Python se'm va demanar si Creant Bits seguiria essent gratuït. La resposta es sí, Creant Bits és una aportació al moviment del programari lliure, com ho poden ser alguns dels apunts del blog, o altres projectes en els particip. No crec que es pugin considerar cursos en el sentit que l'objectiu del Creants Bits no és que la gent surti amb un coneixement profund de la tecnologia, sinó el de presentar el que es pot fer, parlar, reunir-nos i animar a la gent a provar coses, donant-los el primer impuls.

Els cursos sí que els cobr. Quan una empres em demana un curs de Python i Django els objectius és que la gent que participi surti amb un domini del temari que els faci ser productius una vegada acabat el curs. Són moltes hores de curs i moltes hores de preparació per la meva part. L'horari del curs, la localització i els assistents són responsabilitat de l'empresa que em contracta i és aquesta qui fitxa els objectius.

A Creant Bits ens reunim amics i coneguts, gent que ja ens coneixem de manera física i virtual o que tenim ganes de conèixer-nos, amb ganes d'aprendre coses i relacionar-nos. Potser al llarg del temps i amb diferents trobades la gent que participa es veurà amb un coneixements semblants als que tindria amb un curs formal, però això serà tant per l'impuls de la xerrada com per la seva iniciativa personal, i això crec que és la diferència fonamental amb un curs. A un curs vols que la gent surti preparada amb tants coneixements com sigui possible en un temps raonable, a una trobada com Creant Bit a mi el que m'agradaria és que la gent sortís amb motivació per poder començar, amb una petita llum a la foscor, que permeti, amb el seu esforça personal, avançar en el món del programari.

M'estic extenent molt amb aquest tros, però és que veure tanta gent reunida perquè sí per mi ha estat molt important, ja que ha representat passar del món de les idees al món de l'acció, del món de les intencions als fets. L'injecció de moral per mi (i esper que per als participants) ha estat grandiosa i tenc ganes de repetir l'experiència al 2010.

APSL

Al 2009 hem consolidat APSL, l'empresa de la que són CEO i soci. És una empresa atípica, feta a la nostra manera d'entendre els projectes, amb l'ètica al davant, sense voler tenir clients captius sinó essent-ne col·laboradors. Volem fer partíceps a les empreses del que significa el programari lliure, de com les coses es poden fer d'una altra manera fins i tot amb els pressuposts.

Estam intentant rompre amb la idea de pressuposts tancats per a projectes de programari. Creïem amb la idea de que el pressupost inicial ha de ser orientatiu, que després el que importa és que el programa que s'entregui representi el que necessiti l'empresa, que no és necessàriament el que l'empresa vol a l'inici del projecte.

No és una tasca senzilla, representa canviar un poc les regles del joc. Actualment les negociacions d'un projecte sempre estan encaminades a que el risc del projecte ho assumeixi una de les parts. El client intenta que sigui l'empesa desenvolupadora la que assumesqui el risc intentant tancar el mínim possible. L'empresa de programació intentant minimitzar el risc mirant de tancar-ho tot i de protegir-se en el pressupost. És una situació un tant perversa, en la qual tothom hi perd en un moment o l'altra, com en una ruleta russa.

Tot projecte té un risc i aquest hauria de ser compartit i minimitzat. Creim amb la idea d'Scrum com a metodologia de desenvolupament i com a manera de facturar a un projecte. El client assumeix un cert risc: el pagament anticipat d'una quantitat i l'empresa n'assumeix un altre: que l'empresa en qualsevol fita del projecte pugui tancar-lo, dient que el que té ja és el que volia o donar-lo a un altre proveïdor.

El 2010 m'agradaria que fos un any de creixement per APSL perquè voldria dir que aquesta filosofia de treball i gestió ha estat entesa, que una altra manera d'entendre la relació empresa-client és possible.

Gestió de projectes

A 2010 m'agradaria aprofundir en el tema de l'estimació de projectes des d'un punt de vista col·laboratiu. Una de les mancances que tenim com a col·lectiu és que estam massa encaixonats dins la nostra manera de veure les coses, potser sense tenir massa idea del mercat. Són les nostres estimacions raonables? Són les nostres maneres de pressupostar adients? Som competitius? Podem fer alguna cosa per millorar les nostres estimacions?

Crec que es un punt amb la cooperació hi té molt a dir. On podem col·laborar explicant projectes, explicant el perquè de les valoracions i el temps total, per a que serveixin de referència. També es podrien organitzar sessions d'estimació àgil, amb Planning poker estimation. És una idea a la que estic donant voltes però que encara no sé molt bé com organitzar.

També m'agradaria posar en marxa algun tipus de projecte col·laboratiu local, potser lligat al Creant Bits, que servesqui no sols per aprendre sinó també per tenir un producte que pugui beneficiar-nos a tots.

Moltes idees i molts projectes que m'agradaria fer. Tot això s'ha d'acompassar necessàriament amb la dedicació a la família, amb els projectes alimenticis i amb altres projectes que no estan lligats a la informàtica que m'agradaria assolir. Per exemple, no tenc cap coneixement de llenguatge musical, i és una cosa que des de fa anys m'agradaria aprendre. Potser el 2010 serà l'any...

L'any de la crisi

El 2009 passarà per ser l'any de la crisi, però tot i això crec que hem viscut temps interessants. El problema amb la famosa crisi és que tot s'ha enlentit, és com si haguéssim perdut un any, estant a l'expectativa, a veure-les venir. Per mi aquesta expectativa ha estat doble, ja que en hem trobat amb la fusió de TUIE i Hotelbeds, amb la qual cosa molts projectes s'ha paralitzat a l'espera del que passaria.

Com es diu "qui espera desespera", però crec que no ha estat el cas. La sensació de pèrdua de temps és intensa, però tot i això projectes com APSL, el Creant Bits, els passejos amb els nins amb bicicleta i els amics del Twitter no em queda la sensació d'any perdut, sinó d'any de reflexió, de tenir temps de descobrir coses noves i punts de vista diferents.

Encara que molts (la majoria) de pressuposts presentats encara estan al caixó d'algú, poder parlar amb els clients crec que m'ha enriquit com a persona, no des del punt de vista econòmic, però si des del punt de vista espiritual i tot suma!.

Com sempre un espera que l'any que començarà serà millor que l'anterior. Sigui com sigui serà també un any interessant de viure.

Per experiència sé que una de les coses que més ens consta a la gent que fem feina amb bits és posar preu a la nostra feina. Tenim una feina que no entrega un producte físic i on fer i desfer no implica feina física. Si en lloc de vendre còpies el que feim és vendre serveis: programari a mida, configuració de servidors, adaptació de programes, etc. llavors tècniques de màrqueting com les que ens ensenya Neil Davidson a Don't just roll the dice són poc aplicables.

La cosa està en que hem de posar un preu per hora a la nostra feina i aquest preu ho hem de posar amb criteris empresarials, és a dir, valorant el que feim i el que el mercat diu que pot valer la nostra feina.

Per posar aquest preu el que necessitam és una referència. L'ideal podria ser anar al sector i demanar a quant cobra l'hora i quins són els seus marges, però donada la naturalesa de la feina i del sector em tem que aquesta informació estaria ben esbiaixada. A veure:

Una cosa és posar un preu per hora i l'altra és que les hores ens surtin a aquest preu (que és el desitjable). L'ideal és que la desviació entre els dos factors sigui mínim, és a dir, hora feta hora facturada, però això vol dir o bé fer feina amb el que se coneix com a "time and materials", que és el que en construcció se'n diu fer feina a jornal, o bé no equivocar-se massa en els pressuposts i dur un control real de les hores que es fan i de les despeses incorregudes a cada projecte.

Ens hem de plantejar què val el nostre temps i comparar-lo amb el que guanyaríem fent feina amb una altra activitat. Una de les comparacions més senzilles és comparar a quant ens surt l'hora real de feina amb el que ens cobra la netejadora o el mecànic per canviar l'oli, demanar-nos si les hores ens estant sortint millor que si treballàssim en qualsevol d'aquests oficis, o bé si els nostres ingressos són els que són perquè feim més hores que el rellotge.

Crec que és una reflexió personal, però que tothom que fa feina pel seu compte s'ha d'arribar a fer i quan més aviat millor, mentre perquè no començar a dur un control de hores per projecte? Ànims, no és tan complicat, el Trac per exemple té plugins per fer-ho, Eclipse i Netbeans ens permeten controlar el temps que dedicam a cada projecte, fins i tot una llibreteta o agenda que puguem dur damunt ens servirà. No controlar els temps per la gent que viu de vendre serveis és com aquella empresa que no s'empatxa de la comptabilitat i sols sap si té doblers a la caixa o no. Controlar el temps ens permet saber què ingressam en la nostra feina, en què dedicam les hores i poder saber quin és el punt de tall, és a dir, el preu per hora a partir del qual he cobert les nostres despeses bàsiques i començar a poder dir que guanayam doblers amb la nostra feina.

Quan surt aquesta discusió sovint, al manco al meu àmbit, la discusió es redueix a comparar Java i Python. Recentment en Paco ha obert la capsa dels trons al twitter amb una afirmació "Para escribir código mantenible, mejor un L.P. fuertemente tipado. Si es compilado, mejor".

Damunt el tipat o no em remetré al post de Ned Batchelder i a un comentari d'aquest post, amb al qual hi estic d'acord en un 90%, que traduït lliurement i sense limitar-ho a java diria:

1. Python maximitza la productivitat dels bons programadors

2. Els llenguatges tipats (Java a l'original) minimitzen el mal que els programadors mediocres poden fer al sistema.

Tant de bo la segona afirmació fos certa. La gent pot ser molt creativa i cap tipat del món no pot evitar que es faci un borrat complet contra la base de dades, que s'equivoqui amb l'algorisme del càlcul de l'IVA, les possibilitats són infinites. La referència obligada de que el tipat fort no és cap garantia de mantenibilitat la tenim al post How to Write Unmaintainable Code o passar-se per The daily WTF. El primer cas és fins i tot més sagnant, ja que la gran majoria d'exemples i tècniques es refereixen a llenguatges fortament tipats com el C, C++ i Java. Usos creatius del define, noms de variables que no tenen res a veure amb el que fa la variable, noms lleugerament semblants que fan coses totalment distintes,...

No vull fer sang damunt el tipat fort, la majoria de les coses que expliquen al How to Write es poden extrapolar a qualsevol llenguatge de programació. Però la realitat és el tipat fort no és cap garantia de mantenibilitat.

La mantenibiliat ens la donen les convencions del codi, la documentació, la inspecció periòdica o sistemàtica del nostre codi (o del codi d'altres), el llegir el code complete i aplicar els consells i pràctiques també ajuda força. Tenir test unitaris, programes que ens gestionin l'adherència als estàndarts i la complexitat del codi (n'hi ha per Java, Python, C++, ...), gestió acurada del errors, tests de regressió, etc. a l'hora de la mantenibilitat poden fer molt més que el simple tipat.

Potser perquè molts de programes que he fet al llarg del temps s'han mantingut en producció durant anys sóc un tant fanàtic de la mantenibilitat, preferesc codi matenible a codi guais que al cap d'un mes ningú, ni el seu creador, sabrà perquè ho va fer d'aquella manera. I aquest tipus de mantenibilidad no la dóna el tipat fort o el compilador, la mantenibilitat ens la dóna la gent i les regles que ens imposem a l'hora de crear el codi.

Com la seguretat la mantenibilitat no és quelcom que es pugui posar una vegada el programa està llest. La mantenibilitat ha de formar part del procés de desenvolupament. Sovint he refet o he fet refer codi perquè era mal de seguir, per massa acoblament, perquè la quantitat de ifs feia difícil saber per on anava el codi, i això m'ha passat tant en Java, Pascal o FORTRAN com en Python.

Llavors, pensant en que els programes es fan per a ser mantenibles tant en llenguatges tipats com en els no tipats, la pregunta que ens faríem doncs és perquè triar un llenguatge o un altra i aquí ja entraríem en un altre tipus de discusió.

Si pensam sols en termes de mantenibilitat i suposant que programam com toca potser estarem d'acord que hauríem de triar un llenguatge que fos bo de llegir, de seguir, expressiu i d'alt nivell. El millor codi és aquell que no s'ha d'escriure. Per mi pocs llenguatges compleixen això tant bé com Python, és un llenguatge molt clar de llegir, amb una corba d'aprenentatge molt suau i amb una dèria cap a la llegibilitat i la mantenibilitat que està incorporada al llenguatge dins la pròpia sintaxi (la identació) i a l'intèrpret mateix (provau import this) o llegiu The Zend of Python i les convencions de codi són públiques i definides des del 2001, la qual cosa no vol dir que no s'hagin canviat al llarg del temps.

En conclusió: el codi mantenible no ho dóna un compilador sinó el programador i la gestió que se dugui del projecte. No podem confiar en que el tipat fort ens farà la feina i ens alliberarà de la feina de crear tests unitaris, de comprovar que el codi està d'acord als estàndards o de que fa el que ha de fer.

Java, C, C++ són grans llenguatges no perquè tenguin tipat fort, sinó pel que els programadors hem fet amb ells. De la mateixa manera Python, PHP, Perl, Ruby són grans llenguatges no per la seva absència de tipat, sinó per codi que ens permeten escriure.

Disclaimer: Avuir parlaré un poc de jo. Em sap greu pel qui tengui que aguantar les meves batalletes, però com molts sabeu mantenc aquest blog perquè m'agrada i a més em desestressa, ja que em permet reflexionar i posar en clar pensaments que d'una altra manera quedarien fent voltes pel cap.

Mode batalleta ON!

Potser us n'haureu adonat que tenc dues feines: la principal, com a cap de projecte web a una important empresa turística i APSL una aposta de futur junt amb altra gent i que em permet explorar camins que em serien molt difícils de seguir a l'altra banda. Potser hauria d'afegir una tercera, la de pare de família, però deixem-ho aquí, ja que si bé te a veure amb la gestió de projeces, no té res a veure amb la programació :)

Fa uns anys l'empresa principal es fa fusionar amb un altra d'igual tamany i ara han arribat a IT les onades del tsunami en forma de subrogació de contractes. Dins la xerrada damunt el que es guanya i el que es perd per mi té molt manco importància el fet monetari o de posició com el concepte de "qualitat de vida".

Com podreu suposar m'agrada la feina que faig. Cap feina és perfecte i per això APSL cobreix la part que a l'altra li falta: possibilitat de relacionar-se amb clients externs, contacte amb el mercat real, gestió des de zero de l'empresa, ...

La subrogació d'empresa en principi implica mantenir les mateixes condicions laborals, però òbviament la part subjectiva, el que jo anomen qualitat de vida canvia o pot canviar. I com que m'agrada fer llistes us explicaré algunes de les coses que més valor.

• La diversió. M'agrada divertir-me fent feina. Sentir passió pel que faig, superar reptes i posar coses en marxa i acabar-les. Per mi avorrir-me no és tenir poca feina, un es pot avorrir estant les vuit hores fent el mateix o no fent res. No avorrir-se és fer el que a un el motiva i li agrada, i per mi això és fonamental. Passam massa hores a la feina com per passar-les a disgust. Trob que aspirar a fer una feina que t'agradi i que a més et paguin és una aspiració a la que no s'ha de renunciar.

• La proximitat. No m'agrada conduir, i no m'agrada estar 40 o 50 minuts a la carretera. Si no em fes res podria estar fent feina a la Península per molt més sou, però valor molt la qualitat de vida que em dona plantar-me a l'oficina des de Binissalem en 15 o 20 minuts i tenir temps suficient per arribar a fer un cafè. Fa anys vaig canviar de feina, estava a Viajes Iberia, el factor decisiu va ser el que necessitava 40 minuts per aparcar i anar a l'oficina, més 20 minuts de trajecte. Estava molt bé allà, però per mi això no és qualitat de vida, i és una de les feines o he estat més còmode, amb companys i caps magnífics.

• L'horari. Cap horari és perfecte, d'això en sóc ben conscient. Tot i això m'agrada que el meu horari em permeti arribar a casa a temps per ajudar els menuts amb la tasca, amb temps per llegir, amb temps per dedicar-ho a APSL. Està clar que no necessàriament tot al mateix dia i a la mateixa vegada. M'agrada més un horari continuo que un de partit, i si no pot ser un horari compacte. Les guàrdies no m'agraden pel que signifiquen a l'impacte de la vida familiar.

• El lloc de feina. M'agrada tenir una taula ampla. Sóc molt dispers amb els trastos i m'agrada tenir a mà llibres, apunts i al manco dos ordinadors. La cadira se suposa còmoda i el monitor decent, quan puc triar jo dos monitors (a casa i a APSL). M'agrada tenir a mà una pissarra i un lloc de reunions on fer els scrums diaris. M'estim més el silenci que el renou i m'agrada poder sentir la llum solar. Tenir una cafetera és fonamental i millor encara si el cafè és bo i el paga l'empresa.

• De l'ambient. No sóc classista, trob que la relació amb la gent ha de ser franca i oberta independentment del rol de feina que tengui cada un. No m'hi trob còmode en ambients on per tenir una carrera laboral has de llepar culs i riure gràcies quan no en tenen i no fer-te amb els subordinats. M'agrada que em diguin les coses amb franquesa, educació i a la cara, i procur fer el mateix. Intent separar la persona de la feina, encara que sé que és difícil. Si algun aspecte de la feina de la gent del meu equip no m'agrada procur fer-li saber, no com a retret, sinó com a ajuda. Tant fa lo bé o malament que me caigui una persona fora de la feina, dintre a més de l'amistat hi ha una relació professional, una feina a fer i un grup en el qual tots depenem de tots.

• De la tecnologia. M'agrada fer les coses de la manera més eficient possible o al manco tan eficientment com es pugui. Sóc partidari de tecnologies obertes i de llenguatges de programació i metodologies àgils. No conceb la programació sense un sistema de control de versions. Poder fer projectes amb Python és part de la diversió.

• De la gent. M'agrada la gent amb iniciativa, que proposi coses, que accepti noves idees. Valor molt poder confiar en que la gent amb dirà que estic equivocat si troben que ho estic o que seran lliures de proposar millores i noves maneres de fer les coses. Hi ha gent que se sent còmode amb pilotes i beneits perquè no li fan hombra, a mi m'agrada poder dir que faig feina amb gent que és tant o més vàlida que jo.

Ens passam molt temps a la feina i crec que ja tenc prou experiència com per valorar aquests factors subjectius tant o més que una promesa de projecció de carrera o incentius econòmics. El sou és important, no diré que no, però a l'hora de agafar una feina o de decidir deixar la que tenc el que pesa no és tant el sou com les perspectives de millora en qualitat de vida, en tenir una feina prou interessant com per a que valgui la pena aixecar-se cada dia per anar a la feina.

Mode batalleta off!

Aquesta setmana he acabat de llegir Lean Software Development, An agile toolkit de Mary i Tom Poppendieck.

El llibre descriu la metodologia anomenada Lean Development, un conjunt de pràctiques i consells que ens poden ajudar a agilitar els nostres desenvolupaments i minimitzar el riscs dels nostres projectes.

El Lean Delopment és la translació de les pràctiques de desenvolupament de vehicles de Toyota al món del programari, que es resumeixen en set principis:

• Eliminar la brossa. Tot allò que no aporta valor al producte des del punt de vista del client és brossa.
• Potenciar l'aprenentatge. El desenvolupament no és duu bé amb pràctiques que fermen la gent, les típiques de la producció en cadena de bens de consum.
• Decidir el més tard possible. Deixar els desenvolupaments oberts als canvis, de manera que cuan la decisió es prengui es pugui aplicar el més aviat possible.
• Entregar el més aviat possible. Els cicles de desenvolupament han de ser curts i permetre a l'usuari i al programador entendre millor el que es vol mostrant el que ja es té fet.
• Potenciar l'equip. Els programadors saben fer la seva feina, i la millor manera de gestionar un equip no és mitjançant el mocromanagement sinó donant-los marge de maniobra i capacitat de decidir.
• Construir pensant en la integritat. La integritat és allò que l'usuari perceb com a un tot, com un producte redó, i allò que el programador a nivell intern perceb com a un tot que funciona.
• Veure el conjunt Evitar la micro-optimització i la suboptimització, és allò de que els arbres no et deixin veure el bosc.

Els autors proposen 22 eines per pensar, que desenvolupen aquests set principis i ens fan reflexionar damunt el que és el desenvolupament de programari i el paper que e el Lean Development dins el conjunt de metodologies àgils.

El Lean Development més que una metodologia és una filosofia de desenvolupament. Xoca frontalment amb ISOs i CMM i totes aquestes coses oficials amb tantes sigles. Amb tot allò que vol fer que el desenvolupament de programari s'assembli a una cadena de muntatge, ho resumeix molt bé a una cita de McNight "If you put fences around people, you get sheep. Geve people the room they need.". Tanmateix la manera clàssica de fer de les cadenes de muntatges s'ha demostrat ineficient i per tant passar-ho al programari és intentar aplicar una metodologia que ja se sap que no és bona.

També toca un dels aspectes més problemàtics del desenvolupament: com s'apliquen les metodologies àgils quan un fa feina per tercers i té que fer un pressupost. El Lean development té com a filosofia donar al client allò que necessita en lloc d'allò que ha demanat i això no encaixa massa bé amb especificacions tancades i pressuposts clau en mà. El llibre proposa tot una sèrie de tipus de contracte diferents dels habituals. Un dels que més m'ha agradat és el co-source contract, on les dues companyies fan feina juntes i hi ha una transferència de coneixements del venedor al client.

El tema de l'aplicabilitat de les metodologies àgils quan fas feina per un tercer és sempre problemàtica. S'han d'explicar molt bé les coses i el client ha de tenir la voluntat d'entendre i la confiança mútua de que cap de les parts intentarà aprofitar-se de la bona fe de l'altra. Els contractes a preu fitxe donen lloc a usuaris insatisfets - veure també Is Fixed-Price Software Development Unethical?- però en la meva opinió l'usuari també ha de ser conscient del que està demanant al desenvolupador. Si la seva intenció és transferir el risc del projecte a l'empresa desenvolupadora llavors segur que hi haurà problemes, ja que el venedor intentarà protegir-se fent exactament el que diuen les especificacions.

M'agrada la definició de confiança que els autors atribueixen a Dyer: "la seguretat de que l'altra part complirà amb les seves obligacions i que no explotarà les vulnerabilitats". Crec que és la base d'una bona relació comercial: el comprador no explota al venedor i aquest no se n'aprofita del client més que per l'obtenció d'un benefici just. Ben allunyat del "pelotazo".

Si ja estau familiaritzats amb les metodologies àgils, especialment l'Scrum, els conceptes del Lean Development us sonaran molt. El llibre més que donar consells de com aplicar la metodologia com una recepte, ens convida a pensar en cada un dels conceptes, en cada una de les 22 "eines per pensar" que hi ha al llibre.

El llibre m'ha agradat, potser perquè compartesc molt de la filosofia i pensament que hi ha a les seves planes, el tractar el desenvolupament com a una tasca de persones no reemplaçables, on s'ha de potenciar tant l'individu com el grup. El llibre serveix per a reflexionar, per a pensar en el que estam fent en el dia a dia, diria que el podríem classificar com un llibre d'autoajuda del desenvolupament de programari.

Fitxa tècnica:

Lean Software Development. An Agile Toolkit
Mary Poppendieck i Tom Poppendieck
Ed. Addison-Wesley
ISBN-13: 978-0-321-15078-3

M'agrada llegir llibres damunt metodologies de programació, especialment m'agraden aquells que et fan pensar, és a dir, que no et diuen fil per randa el que has de fer sinó que fan que una vegada llegits quedi un remanent de coneixement aplicable i adaptable a les situacions del dia a dia.

Tot i això sempre me quede un regustet amarg perquè moltes de les coses que s'expliquen les veig massa idealitzades. Sempre hi ha un superusuari, un p_roject owner_, els directius saben el que volen i fins i tot hi ha pressupost per al desenvolupament.

Els projectes són prou grans per poder fe iteracions d'un més o dos, hi ha equips dedicats en exclusiva al projecte, la metodologia que es proposa al llibre (aplicada amb èxit o no) s'ha explicat, s'ha entès i ha estat assumida per la direcció de l'empresa.

El client entén perfectament què és una iteració i el perquè un pressupost tancat no és el més adequat, que les estimacions són sols referències i que podrà veure el progrés del programa sense cap problema.

El client accepta de bon grau les reunions periòdiques, testeja el programa i fa les correccions adients per tenir el que vol, òbviament mai s'entra en coses tan poc agradables com discutir qui es fa càrrec dels canvis...

Potser els països anglosaxons (la majoria d'autors que llegeixo són d'allà) ho tenen millor assumit, o les companyies són més grans i tenen menys por a invertir en desenvolupaments trencadors. Vet a saber, però ara per ara per mi aquestes situacions s'assemblen més a un conte de fades que a una situació real.

M'agrada pensar que potser algun dia em veuré en una situació semblant a la que conten els llibres, però ara per ara, em qued sols amb les idees, que amb un poc de sort em serviran per pensar com millorar el procés de desenvolupament.

En la literatura de gestió de projectes anglosaxona es parla d'un efecte teamicide, és a dir, d'un efecte aniquilador de projectes per referir-se a situacions que per la seva naturalesa més tard o més prest repercuteixen en el rendiment i la cohesió de l'equip de treball, poen-lo dur a la seva destrucció.

Avui parlaré d'una d'aquestes situacions, l'anomenada "no passa res" o en la seva variant de "tanmateix tot seguirà igual".

Supòs que més d'un podrà donar exemples d'aquesta situació i de la poca gràcia que fa. Us pos un grapat d'exemples de situacions:

• L'equip ha fet una recomanació que no ha estat escoltada i arrel d'això s'ha de tornar a refer part de la feina. No hi ha conseqüències de cap casta per la persona que no va escoltar les recomanacions i sí més feina per l'equip.

• S'ha posat al davant d'un projecte algú de provada ineptitud. Tothom sap que el projecte acabarà tard o malament o les dues coses. El projecte acaba com se suposava, malament, i s'assigna al responsable inepte a un nou projecte i a un altra persona a recollir els plats trencats.

• S'ha fet una reunió de varies hores per decidir que en aquella reunió no es decidiria res. S'ha perdut el temps de tots els assistents, però no passa res.

• S'ha fet una reunió per determinar un pla d'acció. Tothom hi està d'acord, però a les poques hores algú ja es surt de l'acordat. Es torna a la situació de desgavell anterior.

• Un membre de l'equip es queixa de mala manera al cap de la feina d'un altre company. No passa res.

L'efecte destructor del "no passa res" ve donat per mor de l'efecte de pèrdua de control que es té damunt la feina. La gent arriba a la conclusió de que faci el que faci tot seguirà igual i que la seva feina o no feina no pot canviar les coses. Per tant s'acaba en gent que fa hores a la feina, però que aquestes no són productives.

Eliminar l'efecte "no passa res" és una tasca de comunicació. Sovint l'interessat donarà molta importància a temes que no la tenen i això se li ha d'explicar, altres vegades el tema sí que té importància, i les actuacions que se'n derivin (tot i que poden ser duites dins la discreció) s'han de fer públiques, potser sense assenyalar culpables però sempre fent saber que les coses es prenen seriosament.

L'opció de no fer res sols du a la desconfiança i a la deixadesa. El problemes grans de demà són els problemes petits que no hem resolt avui.

El principi KISS és una d'aquelles regles fonamentals en la programació i gestió de projectes. Ens diu que hem de procurar que el nostre producte, codi, projecte es mantengui el més simple possible, però contràriament al que algú es pugui pensar, això no implica pèrdua de potencia o funcionalitat, ben al contrari.

Fer les coses simples implica aturar-se a pensar en el que un està fent, demanar-se si hi ha una manera més neta de fer-ho, una manera més senzilla, i si hi és aplicar-la, està doncs molt relacionat amb un terme fonamental en la programació: la refactorització.

El problema doncs és adonar-nos de quan estam complicant les coses de manera innecessària i per això és necessari tenir la ment oberta, ja que sovint estam tan aprop del nostre propi codi que ens costa tenir la perspectiva suficient com per veure que el que estam fent es pot fer d'una altra manera.

Una de les maneres més efectives és intentar explicar a algú com funciona, com ho hem fet. Explicar implica recapitular, tornar a pensar en el que hem fet i encara que el nostre interlocutor no faci "carusses" potser ens trobarem reflexionant damunt la complexitat del que estam dient.

Una altra bona opció és documentar, l'aplicació , el codi. Quan documentam l'aplicació es fa una cosa semblant a l'explicació i té el mateix resultat, quan documentam el codi i ho rellegim ens podem adonar de la seva complexitat: si la documentació ha d'explicar com es fa en lloc de què fa el codi, segur que ens hem botat la regla KISS.

Si hi ha alguna cosa en aquest món que compleix el segon principi de la termodinàmica és el codi i els programes. Esforçar-se en fer les coses de la manera més simple ens proporciona un punt de partida que ens permetrà allargar la vida del codi i disminuir-ne el temps de manteniment. Hem de tenir clar que l'entropia és una força de l'univers, no podem guanyar, però podem fer que el desastre arribi més tard.

Però la regla KISS no s'aplica sols al codi, l'hem d'aplicar també als projectes i també se l'haurien de fer seva els usuaris. Mantenir un projecte simple implica fugir de funcionalitats innecessàries, saber quan hem d'aturar i limitar l'abast del projecte. Per això també ens serà d'ajuda un altre acrònim: MOSCOW. La simplicitat al projectes és doncs poder destriar bé el gra de la palla, el que és necessari i el que no.

Els programadors tenim tendència a afegir funcionalitat "per si un cas", codi que no sabem si s'utilitzarà mai, i que potser el que estigui fent és limitar-nos en el futur. Potser l'allau de funcionalitats és quelcom que fa vendre el producte, quantes vegades hem vist com es llancen versions noves de programari que mantenen els mateixos errors però amb noves funcionalitats! Però en el programari desenvolupat per ser utilitzat per l'empresa, mantenir-se dins del necessari implica menor cost inicial i menor cost de depuració i manteniment.

De fet, quan s'ha de pressupostar el cost d'un projecte es distingeix entre projectes que s'utilitzaran sols a l'empresa dels projectes que s'han de distribuir massivament. Els segons tenen un cost molt més elevat, ja que tenim la necessitat d'una depuració més exhaustiva i també perquè sabem que aniran carregats de funcionalitats sols necessàries per a vendre el producte.

Sovint quan desenvolupant programari d'ús intern caiem en el parany de voler tractar-ho com si fos programari de venda comercial. El programari que desenvolupam per al client intern ja el tenim venut, no hi ha d'haver un marketing basat en les n-mil característiques que fa més respecte la competència, sinó en la funcionalitat que dóna, en la diferència de cost o de control que ens dóna fer les coses amb el nou programari en lloc de fer-ho com es feia abans. Això vol dir, concentrar-se en el fonamental, mantenir el programa simple i funcional des del principi, ja que amb l'us segur que s'anirà complicant, no ho compliquem de sortida.

A la gent que ens comana el projecte els hauríem de fer partíceps de la regla KISS, fer-los conscients de la importància de separar l'essencial de l'accessori, del cost que suposa complicar innecessàriament les coses.

Fer les coses simples és molt complicat, no hi ha dubte, és més senzill fer-les complexes sense pensar en les conseqüències, però llavors voldrà dir que no estam fent bé la nostra feina.

M'ha agradat molt l'anàlisi que fa Bruce Momjian al seu blog damunt el nombre òptim de paràmetres de configuració d'una base de dades al seu apunt The optimal Number of Database Performance Settings.

Fa una interessant reflexió damunt com un nombre molt gran de paràmetres de configuració al final resulta en una menor taxa de tunning de la base de dades, ja que la gran quantitat de paràmetres a tocar fa que el nombre de gent que s'atreveix a tocar-los sigui cada vegada menor.

En altres àmbits de la informàtica ens trobam un problema semblant en l'anàlisi de requeriments, és el que es coneix com anàlisi paràlisi. És a dir, quan l'obsessió per tenir-ho tot ben lligat fa que no arribem a tenir res.

Metodologies com Scrum intenten evitar aquesta situació proposant un model de desenvolupament iteratiu i adaptatiu, en el sentit de que no fa falta tenir-ho tot al 100% analitzat per començar. Es parteix de la idea que això sols fa el projecte inviable i el que propugna és que a tot projecte hi ha canvis i hem d'estar preparats per evolucionar el projecte amb els nous requeriments.

A la gestió d'una empresa o d'un departament informàtic també ens podem trobar amb aquest antipatró.

• Al departament informàtic: informes de planes i més planes amb estadístiques de seguiment de projectes, ratios, gràfiques, etc. etc. que no se mira ningú i de les quals ningú treu cap conclusió.

• A la gestió de projectes: obsessió per tenir-ho tot a un project, per controlar les línies de codi que fa cada programador, per saber quants minuts dedica a anar a pixar.

• A l'empresa: Sistemes de bussiness inteligence que no s'acaben de posar en marxa mai perquè encara falta aquell informe que estaria molt bé de tenir. Com al departament informes i més informes que al final no s'arribarà a mirar ningú. Quadres de comandament que pareixen mosaics de Gaudí.

Com tot a la vida cal saber què és el més important, i del més importat allò que ens serveix per prendre decisions i allò que permet avaluar l'estat del projecte, empresa, departament... A un projecte no és tan important saber quantes línies escriu un programador sinó quina és la quantitat de tasca que queda per fer. No és tan important saber qui ha fet un error com saber qui el pot corregir. No és tan important el control damunt la gent com saber que la teva gent no necessita ser controlada.

Demanar massa informes sols pel fet de tenir-los és un signe clar de que quelcom no funciona com hauria de funcionar, que en lloc de gestionar la productivitat s'està gestionant l'ocupació de la gent.

A l'hora de demanar un informe, preguntau-vos per a què ho necessitareu, quines hipòtesis voleu demostrar, durant quant de temps es vol dit informe, i sobre tot, demanau-vos si tendreu temps per a mirar-vos-lo i treure'n conclusions. En cas contrari pot passar com el nombre de paràmetres d'optimització de les bases de dades: teniu tant per mirar, tant per remanar que no sabeu el que és realment important i acabareu sense fer res.

Avui he llegit pels RSS dos apunts que m'han agradat:How Are You Staffing Your Startup? i Outsourcing Killed By Django And Ruby On Rails

El primer apunt reflexiona sobre el paper dels administradors de sistemes als equips de desenvolupament, a les startups. La veritat és que no hi puc estar més d'acord, especialment quan la feina té a veure amb la web.

Entenc la web com una feina d'equip, on es necessita, a més de la idea, els desenvolupadors que la programin, els creatius i maquetadors i la la gent de sistemes per a que ho posi en producció i tengui cura de l'estabilitat del sistema.

Pens que a part de l'èxit d'una aplicació hi té molt a veure l'entorn on es desenvolupa, tenir un entorn de preproducció adequat, tenir un entorn de producció escalable. Que la gent de sistemes pugui dedicar temps a monitoritzar l'aplicació, a millorar les eines que té a cercar o crear-ne de noves.

L'altra apunt fa referència a com Django i Rails poden canviar la mentalitat d'outsourcing de les empreses. Ambdós bastiments fan que el cost de les aplicacions sigui menor i que la quantitat de codi repetitiu que s'escrigui sia molt menor que en les aplicacions escrites en Java (o .Net donat el cas).

Potser l'article no està redactat de manera molt afortunada (ja veureu els comentaris), però crec que la idea és vàlida. Django i Rails permeten fer més coses amb menys gent, però a més fa que la gent millor encara destaqui més i sigui més productiva, ja que l'hem alliberada de gran part de les tasques repetitives que no aporten valor i que precisament són les que tenen més sentit externalitzar.

Això no vol dir que la gent de la India els països de l'Est o Sudamèrica no sigui creativa, sinó que senzillament no fa falta treure les coses fora quan a casa t'ho poden fer igual o millor a pràcticament el mateix cost i temps.

Dugem les coses un poc més enfora. Suposem un projecte gran, 100.000 línies de codi Java pel cap baix. Aquests tipus de projectes són els que normalment se durien cap a consultores de fora. Amb Django se pot convertir en un projecte de 20.000 línies tranquilament i llavors els projectes que es treien fora perquè no hi havia mans per al desenvolupament es poden posar en mans d'empreses d'entre 5-10 desenvolupadors amb garanties de que el projecte s'acabi i s'entregui. En poques paraules, es pot passar de les macro-consultores a les PYMEs altament especialitzades i localitzades fins i tot al territori de qui demana l'aplicació. En la meva opinió això és bo, ja que per una part abaratint els costs fa possible que es puguin fer altres projectes, però a més perquè s'està afavorint un treball de qualitat, no basat en la força bruta sinó en la capacitat de l'equip.

He passat una estona rient pel post de James Carr anomenat Why must people degrade my profession. Pareix que aquestes situacions no són sols patrimoni dels informàtics patris, sinó que també companys de professió d'altres bandes també s'hi troben.

Potser l'article (el rant millor dit) ens fa gràcia perquè ens hi veim reflexats, però està clar que quan hom viu la situació no li fa gràcia.

Record que estan al càrrec del departament de suport de l'empresa un dels operadors va rebre una trucada, feia poc que s'havien començat a instal·lar impressores a color i algunes donaven problemes. Així que quan l'usuari va cridar i va dir que tenia problemes amb la impressora el primer que va dir el tècnic és:

(en castellà a l'original)

• ¿Impresora de color?
• Sí, claro, de color gris como las otras

Jo que l'escoltava em tirava pel terra, però a ell no li va fer gens de gràcia us ho assegur.

Hi ha una màxima que diu que no s'ha atribuir a la mala fe allò que es pot atribuir a l'estupidesa, i en soc un ferm partidari, però està clar que l'estupidesa a grans dosis pot ser desesperant. Ja sabeu: l'intel·ligència humana té un límit, l'estupidesa no.

Quan un es dedica a la gestió de projectes i a la programació les situacions són unes altres, però sovint també te dóna la sensació de que estan degradant la professió, bé per estupidesa, be per mala fe.

Curiosament el que sí me trobat és que aquestes situacions no es donen als projectes privats i sí als projectes d'assalariat.

En el primer cas la gent sol tenir més o manco clar el que vol, sap que la teva feina té un preu i que li cobraràs per allò que demani. S'escolten molt més quan els dius: "sí, això se pot fer, però serà car, te propòs que ho facis així i així i et sortirà més barat, tendrà més rendiment, etc.". Agraeixen la teva feina de consultoria i tu acabes satisfet per haver donat una solució al client, ja convertit en amic, que li estalviarà diners i que a més li permetrà tenir un sistema o aplicació de la qual tu també te'n sentiràs orgullós.

Perquè això és important. Per un bon professional, a més del sou hi ha l'amor propi d'haver fet una bona feina. Això no és patrimoni sols de la informàtica, he vist el mateix en picapedres, fontaners, sabaters, metges, ... Independentment de la feina són persones que tenen una cosa en comú: que estan orgullosos de la feina que fan i la volen fer el millor possible.

Pareix, o al manco així em passa a mi, que la cosa canvia quan qui comana la feina no s'hi juga res, i encara és pitjor si qui ho comana no és el mateix que ho ha de fer servir. Aquí les situacions que m'he arribat a trobar són directament de vinyeta de Dilbert. Si fa uns anys algú m'hagués dit que l'empresa posaria webs sense continguts i que no passaria res no m'ho hagués cregut i ja en duim dues d'aquestes.

Tècnicament n'estic orgullós: les webs són ràpides, escalen bé, s'indexen bé... Però com a professional no puc sentir-me còmode amb la situació, m'agradaria veure la feina acabada, poder dir "veis això ho hem fet nosaltres" i no quedar empegueït.

La situació és encara pitjor quan intentes explicar les diferència entre una web B2C i una web B2B, del perquè algunes coses que es fan a un B2B on controles qui es pot connectar, el creixement de les peticions, al cap i a la fi; no es poden aplicar a webs on no saps com s'utilitzaran, ni si demà sortiràs a l'Slashdot o al meneame, o senzillament faran servir els teus serveis moltes planes que a la seva vegada no saps el nombre de visites potencials que poden tenir. Això que hauria de ser molt clar per qualsevol que entén com funciona Internet sorprenentment no es considera ni es vol considerar.

Com que ningú s'hi juga res, ni tan sols el prestigi, la posició que adopta alguna gent és la de no deixar fer la feina, deixar que el temps passi i evitar que els projectes avancin. No sé si això es fa de manera conscient o inconscient, però es una dinàmica descoratjadora per la gent que ens consideram bons professionals, que ens sentim orgullosos de que els projectes surtin i vagin bé.

Permetre dins una empresa aquest tipus d'actituds i no fer-ne res, és per mi un exemple de degradació de la professió i potser fins i tot de l'empresa. Per mi és pitjor que el que explica Carr, ja que en el seus cas i com apunten els comentaris, el que vol l'usuari és algú que li pugui resoldre els problemes i acudeix a qui té més aprop que creu que en sap més que ell. En el segon cas la degradació és més greu, ja que potser no és tan visceral, però sí que toca més els fonaments de la professió i amb unes repercussions molt més profundes, tant econòmiques com de motivació de la gent.

Pens que tothom tenim un llenguatge de programació que ens és afí, com al Harry Potter amb les varetes, podríem dir que no és el programador qui elegeix el llenguatge de programació, sinó que hi ha un llenguatge que encaixa perfectament amb la manera de pensar del programador.

En la metodologia de gestió de projectes crec que passa un poc el mateix. Quan hom pensa que el més important en els projectes són les persones i s'ho creu, les metodologies clàssiques no encaixen, ja que tenen tendència a pensar que els programadors són intercanviables, com un peó de la cadena de producció.

Quan es posa èmfasi en que la programació la fa la gent i que el factor realment diferenciador en la productivitat i l'èxit d'un projecte no és tant l'eina de programació com la gent que hi ha implicada, arribarem prest a les metodologies àgils.

Dins aquestes n'hi ha una que a mi m'escau d'allò més bé, en que m'hi sent més identificat i aquest és l'Scrum.

L'Scrum és una metodologia senzilla, on l'equip ho és tot i el cap de projecte no diu el que s'ha de fer sinó que és un facilitador, és a dir, la persona encarregada d'eliminar els obstacles que puguin posar en perill [1] el projecte.

Scrum fuig de la idea de que s'ha de tenir tot totalment clar abans de començar i abraça la idea del canvi, del dinamisme en els projectes. M'agrada perquè va per feina, sols amb la mínima cerimònia i sempre amb l'objectiu de que el client acabi obtenint allò que necessita i que sovint no és allò que havia demanat inicialment.

[1] "Pero que parezca un accidente"

L'altra dia una persona es va posar en contacte amb mi per a veure si li podia ajudar en un projecte, que resultà ser un deathmarch en tota regla.

La cosa és que l'home es queixava de que no trobava gent formada en Python i Django. Normal, la gent formada està fent feina i la tecnologia és prou nova com per a que encara sols la gent amb més inquietuds informàtiques hi estigui aficada.

Personalment crec que és part de la responsabilitat de l'empresa la de formar els seus treballadors, i la d'aquests aprofitar les formacions obviament. Per una empresa l'objectiu fonamental seria el de tenir treballadors capaços de autoformar-se, d'aprendre noves tecnologies ràpidament. Després de tot la tecnologia, especialment la tecnologia web, avança a un ritme tant alt que l'expert d'avui es pot convertir en l'inútil del futur.

En els darrers mesos he estat donant cursos de formació interns amb Python i Django a la gent que desenvoluparà tres dels propers projectes web. Gent que es reciclarà d'altres tecnologies i que té com a denominador comú les ganes i la capacitat d'aprendre.

De l'experiència actual n'he tret dues conclusions que vull compartir amb vosaltres:

La formació de 30 hores en Python i Django no és suficient. Em varen quedar molts punts que m'agradaria haver tractat. Tot i això crec que orientar la formació en vàries tandes en lloc de fer maratons seguits permet a la gent assimilar millor els coneixements i donar temps a la gent per a que pugui investigar i anar ampliant coneixements pel seu compte.

El seguiment és fonamental. El mentoring és una tècnica molt eficaç per assolir i transmetre coneixements i és quelcom que no he vist contemplat mai en cap dels cursos que he m'han donat. Les empreses pareix que suposen que una vegada donat el curs l'alumne ja pot volar sol, i realment no és així. El seguiment posterior, l'anar polint imperfeccions, la de fer petits monogràfics dins un projecte concret és una tècnica que personalment m'ha donat molts bons resultats en el passat i crec que aquesta no en serà una excepció. Això si, un acaba molt cansat quan els components de l'equip estan enfora (antiproductiu? sí, no us diré que no, però ja sabeu la dita del català antic, "donde hay patrón...")

La cosa està doncs que la gent comença a ser prou productiva com per fer avançar el projecte, i que tenir un projecte on pot començar des de zero, els ajudarà a fixar coneixements, no tan sols de programació, sinó de la manera pythònica de fer les coses.

Una vegada acabat el projecte sols em quedarà anar a Ca'n Paco i comprar-me unes sabates noves, hauré de passar el ticket a l'empresa :-P

Estar en la zona és estar en el nirvana de la programació, a l'estat mental en que les idees passen a línies de codi, on els dits es mouen pel teclat en un flux constant i quasi hipnòtic.

Estar a la zona no és fàcil però sortir-ne sí. Estar a la zona enganxa, de manera que una sortida de la zona sobtada sovint va seguida d'uns minuts de mala llet, dirigida contra el responsable d'haver pertorbat l'estat mental per excel·lència del programador.

Aconseguir l'estat mental adequat per entrar a la zona és una qüestió molt personal de cada programador, però ho podríem comparar amb els rituals de fan els esportistes abans de sortir a competir. Entrar a la zona significa complir amb un ritual, amb una lletania que ens ajuda a aconseguir les condicions de partida que ens han de dur al flux, a la zona. Per un és no tenir papers a la taula, per altres tenir la taula plena de papers, altres han de disposar totes les icones de l'escriptori d'una determinada manera, altres obrim les consoles que necessitarem abans de començar i les distribuïm entre els escriptoris de manera que ho tenguem tot distribuït tal com ens agrada, tal com ens va bé.

Quan un està a la zona el temps passa més aviat, a la darrera compilació li segueix una altra darrera compilació i així successivament, qui està a la zona se'n resisteix a sortir-ne i inconscientment voldria que l'estat de beatitud que es té duràs un poc més. Ja hi haurà temps per anar a dinar, "un moment que ara acab això...", "gairebé ja ho tenc,", frases típiques que a ben segur us haureu trobat dient-vos a vosaltres mateixos o a un tercer.

Per entrar a la zona s'han de donar les condicions adequades, l'ambient de treball hi influeix molt. Si hi ha interrupcions cada pocs minuts normalment ja ni s'intenta entrar a la zona, ja que sortir-ne una vegada hi has entrat és un petit trauma i les persones intentam evitar les experiències negatives.

Per això es recomana que els programadors tenguin els seus propis despatxos evitant telefonades, interrupcions i reunions innecessàries. L'estat mental productiu per a un desenvolupador és el de la zona, és l'estat que el motiva a anar a fer feina cada matí, és una llàstima veure departaments de programació "diàfans" amb telèfons sonant per tot, fins i tot n'he vist que a més de no tenir paret i despatxos estaven aferrats a la cafeteria.

La productivitat en el món de la programació passa per donar a la gent les condicions òptimes per fer feina. L'estructura organitzativa hauria d'estar orientada a que la gent que fa desenvolupament pogués fer-ho amb tranquilitat, gaudint de la seva estada a la zona. Potser per això la majoria gaudim més de la programació a casa que a l'oficina, a casa és més fàcil accedir a la zona i menys complicat mantenir-s'hi.

Aquesta setmana ens hem vist amb la necessitat de crear una aplicació que havia de connectar amb un web service i agafar les dades de l'aplicació legacy que està feta en Oracle.

Hi havia dues alternatives, l'opció de salvemos el culo que implicava fer-ho tot en Java i no arribar a temps, o jugar-nos-la i fer-ho en Python i Django, i aquí el Boogeyman [1], no ens havíem trobat mai amb la necessitat de connectar directament Django amb Oracle, així que el primer de tot va ser veure com es podria fer i si ens trobaríem algun problema.

Per connectar amb Oracle, s'han de fer servir una llibreria anomenada cx_Oracle i de les llibreries d'Oracle mateix. Com que no vaig trobar les llibreries per la meva versió d'Ububuntu, doncs a compilar toca!. Vaig trobar una guia força bona a la web, sols vaig necessitar instal·lar una llibreria addicional a Ubuntu - si no la teniu en executar us petarà per a que no la troaba, i posar les llibreries d'Oracle a l'ldconfig.

Així doncs, vençut el Boogeyman, tota la resta era conegut i controlat: els serveis web amb ZSI encara que pot resultar un poc embullat al principi, quan li agafes el què, és molt potent. Si a més li posam una façada per adaptar-ho al que volem, consumir serveis web fets amb SOAP deixa de tenir misteri. Per una altra banda la part de manteniment web amb Django ja està força controlada, i la part de consola que també havia de tenir l'aplicació tampoc era nova. Python de fet té una utilitat anomenada Cmd o també es pot fer servir una utilitat de tercers anomenada cmd2 que hi afegeix algunes característiques interessants.

L'important d'aquesta història, però, no és la batalleta, no és tant veure que es pot fer feina amb Oracle amb Django i Python, sinó adonar-se de que per a que un projecte es pugui dur a terme amb garanties una de les coses més importants que s'han de fer és descobrir aquelles coses que sabem que no sabem i a ser possible descobrir el més aviat possible allò que no sabem que no sabem.

Si en aquest projecte s'hagués començat per altres tasques ens hauríem pogut trobar en dificultats a l'hora d'accedir a les dades i la feina feta serviria ben poc, o si més no, el projecte s'hauria endarrerit. Controlant el primer de tot el que pot donar dificultats augmenta les nostres possibilitat d'èxit.

Del post anterior em quedava el tema de tractar el tema de la capa de negoci en els llenguatges dinàmics. Com en el cas anterior faré servir Django com a exemple i deix al lector la feina d'extrapolar cap el seu llenguatge dinàmic+bastiment preferit.

En Domingo diu que els llenguatges dinàmics mostren molta de la seva potència a la capa de presentació, que és allà on en treuen més profit. Això és veritat però es queda curt. És a dir, quan un usuari demana un canvi, el més habitual és que aquest s'acabi reflexant en la capa de presentació,però això no vol dir que no se canvii la capa de negoci. El fet però és que anar des de la capa de persistència, passant per negoci i mostrar el resultat al navegador, té un cicle de temps més curt en el llenguatge dinàmic, interpretat, que en el compilat, ja que sol ser molt més curt fer els canvis (gearing factor i totes aquestes herbes) i necessitea un temps més curt de desplegament, però no ens enganem, és tot el procés que és curt, si no afecta a capa de presentació el que passarà és que el desenvolupament serà encara més ràpid.

Sovint amb les aplicacions del tipus crea el teu blog en 10 minuts en Django, Rail o qualsevol altra, es dóna una idea equivocada del que se pot fer, donant la imatge de que aquestes aplicacions van molt bé per fer webs que depenen d'un conjunt de taules senzilles i que tenen una lògica de negoci poc complexa.

Bé, supòs que podríem demanar-li a Ricardo, que és un exemple que tenim ben aprop,de com s'ho fa per calcular el karma de Meneame o per saber si una notícia ha de sortir en portada o quan ha de deixar de ser-hi. Tot això es lògica de negoci, està feta en un llenguatge interpretat, el PHP.

En el cas de Django no oblidem que el que tenim per davall és Python i que l'ORM que ens proporciona Django ho podem fer servir o no, substituir-ho per un altre, fer les cridades directament a BD o senzillament, utilitzar-ho com a part del nostre model de negoci i posar-i les regles que ens convenguin.

Segons la nostra aplicació podem anar afegint custom managers que ens permetran definir regles damunt les dades que volem obtenir, mètodes de classe per definir les funcionalitats que vagin damunt tots els elements de la taula, i missatges que ens ajudin a manipular la informació i les seves relacions.

Això ho podem fer directament des de la classe de l'ORM, el model, o bé, recordem que tenim Python a la nostra disposició, crear un nou paquet, crear una classes o un conjunt de classes i utilitzar el model per aplicar les regles de negoci que vulguem quan aquestes s'hagin de convertir en registres de la base de dades o la seva informació hagi de venir de la base de dades. Per cert, i abans que algún ho demani, sí hi ha transaccions!

Això vol dir que podem fer servir els llenguatges dinàmics per a modelar la nostra capa de negoci, doncs sí, ho podem fer. Això vol dir que la nostra aplicació ha d'estar escrita en un llenguatge dinàmic sempre? No, depèn de l'aplicació. Potser per una aplicació concreta amb un requeriments concrets tenir un contenidor EJB amb transaccions distribuïdes serà el que necessitam, el que vull dir és que no podem descartar fer l'aplicació en un llenguatge dinàmic sols perquè ens hem quedat amb la idea de que sols va bé perquè el seu ORM te crea molt fàcilment les taules i els CRUDs.

De fet la part d'administració de Django va molt bé com a eina administrativa, però no és una eina d'usuari final. Com a desenvolupador te va molt bé perquè pots fer cerques ràpidament, començar a omplir les dades del manteniments mestres i anar directament a les butzes de les dades, però no hem de confondre això ni amb l'aplicació final i amb que és tot el que se pot fer amb els llenguatges dinàmics.

I encara hi ha un punt que no hem tractat, el tema de la integració dels llenguatges dinàmics amb els llenguatges compilats (jpython, jruby, groovy, etc). Segons la nostra aplicació i els nostres usuaris, tenir un llenguatge interpretat, fins i tot creat per al domini de la nostra aplicació pot ser una opció molt interessant. Permeteu-me una batalleta: fa un grapat d'anys vaig desenvolupar el programa de gestió d'excursions de l'empresa on feia feina (Delphi + IBObjects + Firebird), una aplicació client servidor clàssica amb un grapat de procediments amagatzemats quan feia falta. La cosa és que hi havia excursions que tenien ofertes que el proveïdor donava i que s'havien de cotitzar, ofertes del tipus: "si es reserva una excursió per dos adults i un nin, el nin tendrà un 25% de descompte damunt la tarifa" o "el tercer adult es gratis i els nins no paguen" etc. Això ho podria haver desenvolupat amb un bon conjunt de camps de la base de dades i tenir previstes les condicions, però la solució hagués estat visualment atractiva però mala de programar i molt propensa a errors. Per contra vaig optar per a modelar-ho con si fos una fórmula de una fulla de càlcul, a la que els meus usuaris estaven acostumant on es podia jugar amb el preu per data, amb sumes, restes, if i tant per cents i parèntesi, un mini intèrpret pensat per a tractar amb fórmules matemàtiques. Les condicions així posades eren flexibles i amb unes possibilitats pràcticament il·limitades respecte al que haurien estat si ho hagués fet amb una "interfície amigable". En aquest cas, integrar un intèrpret a l'aplicació va ser la millor solució.

Com no me cansaré de repetir, no es tracta de dinàmics/interpretats respecte d'estàtics/compilats. Es tracta de perdre la por i els perjudicis i poder triar en cada cas aquella tecnologia que millor s'adapti al problema a resoldre de manera que aquest es pugui resoldre amb el menor cost actual i futur per al nostre client, en alguns casos aquest llenguatge serà C, C++, C#, Java o el que sigui, però en altres, en molts altres un llenguatge dinàmic serà la millor opció per als nostres clients.

En Domingo al seu blog fa una referència al meu apunt damunt llenguatges dinàmics i un bon grapat de bones reflexions.

Això de no creure's el que dic és una postura molt sana, sobretot perquè en la redacció d'un apunt me puc deixar detall i dades que són interessants. Una postura crítica ajuda a reflexionar i a completar les frases que d'altra banda s'haurien deixat com a dogmes de fe. Jo sóc del mateix tarannà, hi ha coses que me crec i coses que a poc que vegi indicis de contradiccions, doncs cerc més informació o deman explicacions. Això, he de dir també, m'ha causat força problemes en el món empresarial, on sovint el "no pensis" és una qualitat que ajuda a progressar.

Bé, però no me'n vull anar per les bardisses, o sí, ja que hi sóm, aprofitaré per dir perquè no faig servir el Twitter: no hi ha espai abastament :)

Afirmació: El nombre de línies de codi que escriu un programador al dia és una constant. Això és un efecte estadístic. Fa temps es parlava de que un programador escriu cinc línies de codi sense errors al dia. Està clar que és una dada estadística i fins i tot controvertida, ja que que és molt complexa definir què és i que no és una línia de codi i de que les línies de codi no s'han de fer servir per mesurar el rendiment. Tot i això podem trobar referències capítol 5 de Software estimation de McConnell on a la Taula 5.1 torbam la relació entre les línies d'un projecte i les línies de codi per programador i any. Això no vol dir que tots els programadors escriguin les mateixes línies de codi (de fet la productivitat entre programador pot arribar a un factor 10 -Peopleware-, però sí que en mitja i per a una organització i projecte, el nombre de línies de codi que s'escriu en promig és constant. A Sofware Mesurement and Estimation diu "Studies have shown that a proficient programmer can programm aproximately the same number of debugged lines of code per day regarless of the language". D'aquí que gent com QSM o David Consulting Group facin comparatives entre llenguatges per a comparar l'expressivitat de cada llenguatge. Per exemple C té un gearing factor de 128 i Java de 53. Això vol dir que una funció que en C necessita 128 línies de codi en Java en necessitarà en promig 53. Si un programador experimentat escriu, essent optimistes 10 línies de codi depurat al dia, llavors necessitarà 13 dies en C i 6 en Java (nombres redons).

D'aquí llavors que els llenguatges dinàmics, al necessitar menys línies de codi per fer el mateix poden completar els projectes en un temps més curt. Com que el temps significa doblers, implica que els projectes surten més barats.

Afirmació: el número de errores directamente proporcional al número de líneas que se escriben Aquí també entram en temes estadístics. De fet es parla de nombre d'errors d'un programa per mils de línies de codi. De la mateixa manera que en el cas de les línies de codi que escriu un programador, hi ha moltes diferències, però Casper Jones a "Program Quality and programmer Poductiviy (1997)" va recopilar algunes dades, que també cita en McConnell. També Reifer en va fer estudis, per exemple per la part Web estudià 65 projectes, i trobà que el ratio és de 6 errors per KESLOC (KESLOC Kilo (Thousand) Equivalent Source Lines of Code). Aquest nombre depèn força del tipus del projecte i de l'organització, però és estadísticament significatiu. Per tant, si donam com a bo el que els llenguatges dinàmics necessiten menys línies de codi per expressar el mateix que els llenguatges compilats tradicionals (Java, C, C+, ...) tendrem que el nombre d'errors en valor absolut també serà menor.

He trobat també una comparativa entre el nombre d'erros per Java i C++ a un paper de Geoffrey Phipps anomenat Comparing Observed Bug and Productiviy Rates for Java and C++, me l'he d'acabar de llegir, però conclou que amb un 95% de confiança C++ té 9,7 vegades més defectes per KLOC que Java i que a més els defectes en Java són més fàcils de corregir. D'aquí a fer una extrapolació cap a la banda dels llenguatges dinàmics hi ha sols un pas, sols falta que algú s'animi a fer l'estudi.

En Domingo també demana l'opinió damunt els llenguatges dinàmics per la capa de negoci, però això crec que dóna per un apunt per ell sol, així que ho deixaré per la propera vegada, però promet, amenaç, amb tractar-ho.

A l'hora de fer estimacions de projectes una de les regles bàsiques que hi ha és que si existeix algun tipus de dada mesurable és millor això que res, i que és millor tenir una dada objectiva i reproduïble que tirar d'arts adivinatòries.

Això és aplicable també a altres àmbits de la programació: en lloc de dir "aquest algoritme crec que millora el rendiment" mesurem els seus efectes abans i després, sols d'aquesta manera podrem avaluar objectivament les millores que tenim.

En lloc de dir "el rendiment en producció serà millor", comprovem-ho, agafem-ne mostres i facem extrapolacions. Comprovem els canvis que feim quan posem cachés, optimitzam la base de dades, augmentam la memòria del sistema i documentem-ho tot.

La informàtica és una ciència i com a tal les afirmacions si no són demostrables i reproduïbles sols tenen sols el valor que els vulgui atribuir cada un segons la solvència de la persona que les fa. Si les afirmacions van acompanyades de mesures i dades, ja no és cosa de creure o no, és cosa de comprovar. Potser per això a tots ens agraden tant els benchmarks.

Recentment he estat fent un poc de recerca per veure com podia aplicar els conceptes d'integració contínua als nostres projectes. El conjunt d'aplicacions que tenim ha anat creixent al llarg del temps i les dependències entre les llibreries i les aplicacions també ho ha fet.

La idea de la integració contínua és que hi ha un mecanisme automàtic que recull les actualitzacions dels diferents repositoris de control de versions que es tenguin i aplica els tests d'unitat per comprovar que tot funcioni i que els tets passen. D'aquesta manera, i si s'han fet els tests, podem minimitzar l'impacte d'un canvi d'una llibreria en les aplicacions, és a dir, si pel que sigui canviam una llibreria i els canvis impacten a una aplicació de manera no prevista, quan construïm l'aplicació no passarà els tests.

El programari d'integració contínua permet seguir els tests, treure'n estadístiques i veure manera integrada què és el que ha fallat o comprovar que tot ha anat bé. A més es pot utilitzar el programari per a la construcció de l'aplicació i el seu desplegament als entorns de proves. Fet i fet, aquest tipus de coses es poden fer molt bé amb scripts i ens asseguram que en tot moment tenim la nostra aplicació a punt.

En entorns on hi ha molta gent, la integració continua garanteix que si algú "peta" l'aplicació amb commit que no passa els tests, aquest fet es descobrirà prest i es podrà minimitzar el seu impacte. La majoria de sistemes que he avaluat a més permeten a més dels tests unitaris, passar tests al codi font per intentar detectar errors, veure que se segueixen les regles d'estil, etc.

Per a les meves necessitats volia que el sistema d'integració contínua fos capaç de fer feina amb Java (la majoria ho compleixen) però que a més pogués passar els tests de Python i que en general pogués fer des de la construcció de l'aplicació, passar els tests i fer-ne el desplegament.

El que més m'ha agradat per ara és un sistema anomenat Hudson. Hudson és una aplicació recent, feta en Java, fàcil de desplegar i de fer anar. La interfície està molt cuidada i té tot el que necessit per començar. A més hi ha un article de com fer la integració per Python, que m'ha anat molt bé per començar.

Hi ha moltes més alternatives, a mi Hudson me va molt bé perquè té tot el que necessit per aquesta etapa del desenvolupament i és prou extensible com per a que pugui cobrir les nostres necessitats del futur proper. Hi ha altres sistemes a on triar, la gent de Confluence n'ha fet una taula comparativa. Mirau i comparau, però si teniu les mateixes necessitas que jo, no deixeu de fer una ullada al Hudson.

Hi ha uns tipus de projectes, normalment petits, que serveixen per provar nous conceptes i idees, que els anglosaxons, sempre tan ocurrents amb els noms, anomenen projectes mascota: els pet projects.

Aquest tipus de projectes estan molt lligats als programadors que els fan, se'ls agafa "carinyo", a força de bregar amb ells provant noves idees. Els pobres però, també solen ser un conjunt de pegats, ja que no es caracteritzen per una arquitectura ben definida i elegant, sinó per ser un conjunt de proves de concepte i de noves rutines que el programador vol provar.

Aquests darrers dies he posat en marxa el meu pet project: a partir de la necessitat de refer una web he començat a desenvolupar el que serà el nou lloc web de No Diguis Dois. Té tot allò que el caracteritza per ser un projecte mascota:

• No hi ha implicació econòmica, la família és la família.
• Es fa a hores lliures
• Hi vaig provant tot el que se m'acud :)

La idea és acabar amb un lloc web on el grup pugui posar la seva biografia, cançons, fotografies i mantenir als fans al tanto de les seves actuacions.

El projecte correrà damunt Django, bé de fet ja corre, però sols a la meva màquina per ara ja que s'han de pujar molts continguts i m'ha servit per provar tot un grapat de pluguins i idees:

• Photologue: és una aplicació Django molt senzilla que s'integra dins l'administrador i que ens permet mantenir galeries de fotos. L'he adaptada un poc per a que estigui en català i per a que s'adapti a les meves necessitats, però m'ha estalviat molta feina, ja que tot el manteniment i les plantilles venen donades.
• jcarousel: Una vegada ja tenim les fotos convé presentar-les bé. Jcarousel és un afegitó per jQuery que ens permet mostrar galeries de fotos. Com que a més volia mostrar la foto en gran, he optat per l'estàndard
• ThickBox : No hi ha prou lloances per aquest afegitó de jQuery que és cada dia millor. En dues potades tenia connectada la galeria de jcarousel amb la presentació del ThickBox. L'exemple del jcarousel ha fet més nosa que servei ja que està molt lligat a mostrar sols una galeria, però sigui com sigui ara puc mostar diverses galeries de fotos i quan se'ns selecciona una passar a la presentació de ThickBox.
• He provat els inclusion tags de Django. Una virgueria de fa poc. El problema era que volia mostrar a cada plana contingut dinàmic i a la mateix vegada no perdre la potència de les vistes genèriques. Els inclusion tags permeten definir en dues potades tags per a la nostra aplilcació, de manera que ara tenc un {% show_components %} com a tag que em permet generar sempre que vulgui la llista de components. Això m'ha permès treballar amb sols amb una plantilla i que totes les altres n'heretin, fins i tot les vistes genèriques i disminuir l'acoblament de les aplicacions com photologue de l'aplicació que he generada per la gestió del lloc web de No Diguis Dois.
• També he fet servir el nou tag per les cachés de Django. Aquest tag ens permet definir una caché sols per un tros de la pàgina web. En el meu cas l'he fet servir per mantenir els menús, part dels quals es genera dinàmicament. El tema de les cachés en Django està força ben aconseguit, es pot cachejar part de la plana, la plana sencera, les dades, o qualsevol cosa que vulguem, ja que tenim accés a l'API, i no tan sols això, sinó triar si volem fer servir la memòria, el sistema de fitxer, la base de dades o el memcached per a gestionar-la.

Encara em queden força coses més a provar, com l'edició en línia dels continguts, però no sé si serà per aquesta versió. Ara els plans són sortir en quant tinguem llests els continguts i netejar un poc el codi i pujar-ho a un repositori subversion public, per si algun altre grup de rock ho pot aprofitar.

Supòs que la web es llançarà poc abans del nou disc, i esper tenir el codi prou netejat com per a poder-ho publicar en condicions. És el que té un pet project, que a la que et descuides te mossega els calçons.

Tret del llibre Software requirements,

L'analista és la persona que ajuda als qui han demanat el projecte [1] a trobar la diferència entre el que ells diuen que volen i el que realment necessiten.

[1] stakeholders a l'original

M'ha feta gràcia la definició perquè és quelcom que sovint és perd al rol d'analista. L'analista ha de poder dir la seva en el projecte, proposar solucions, millores i expressar sense por el perquè troba que el que s'està demanant no funcionarà, o no és necessari.

Encara que se pugui dir que el client sempre té raó, si duim aquesta frase a les seves darreres conseqüències en el desenvolupament de programari, estarem pervertint la feina de l'analista.

És potser el mateix que quan un demana un disseny web i li diu al dissenyador des de com vol el format, les fotos, els colors i la tipografia. Llavors per a què vols un dissenyador web?

Pel que es veu aquest tipus de situacions no és sols pròpia d'analistes o dissenyadors web. Parlant amb un arquitecte em deia que té clients que ja li venen amb els plànols fets i que no atenen a raons, són els que solen acabar amb el bany aferrat a la cuina. També vaig viure una situació semblant amb un interiorista, el client li deia com ho volia tot, col·locació, llums, decoració, fins que l'home l'hi va tenir que dir que aquells temes eren precisament la seva feina.

Potser ens ho tendríem que plantejar de tant en tant allò de dir: "escolta, això és la meva feina, si la vols fer tu endavant però després també t'has de responsabilitzar dels resultats".

Trobar un error al teu codi és un emprenyo. Poder començar la depuració en 30 segons, trobar l'error 2 minuts, pujar-ho al subversion i actualitzar la versió de producció de manera que als 5 minuts d'haver detectat l'error estigui corregit no té preu.

Això és el gran avantatge dels llenguatges d'script, que el temps que passa des de que trobes un error a poder-ho corregir és molt curt (llevat d'excepcions amb errors difícils de trobar i depurar, clar). Curt perquè normalment posar en marxa l'entorn de desenvolupament no duu més que uns pocs segons i ja pots començar a depurar.

Si tot està ben organitzat el codi estarà a un repositori subvesion i l'entorn de producció no serà sinó un client de subversion, de manera que fer una actualització una vegada trobat un error que no afecti a la base de dades, és bàsicament

• svn ci
• ssh al servidor
• svn update

I en alguns casos recarregar l'Apache. Encara desenvolupament i sistemes siguin equips separats, davant un error crític el temps de resposta pot ser tan curt com 5 minuts.

L'experiència amb Java és que ja directament és necessiten els 5 minuts sols per posar en marxa l'entorn, 5 o 10 minuts més per depurar i si hi ha sort i sols era un error de jsp 2 mintus més actualizar i forçar la compilació del jsp per a que el proper usuari no vegi en enlentiment en la pàgina. Normalment més del doble per a corregir el mateix tipus d'error.

Si la correcció de l'error implica canviar codi que no sigui jsp o html les diferències són encara més grans i sovint pot implicar tenir que reiniciar el servidor, la qual cosa ens obligarà a tenir sempre dos servidors balancejats si no volem tenir als usuaris aturats durant 5 minuts. L'Apache es recarrega en segons, i tot i que sempre és bo tenir-ho tot duplicat i balancejat, la necessitat no es tan forta com en el cas anterior.

Personalment m'agrada molt Java i les llibreries que s'han desenvolupat en aquest llenguatge, però si el nostre negoci depèn del ràpid que puguem actualitzar la nostra aplicació web hi ha entorns i llenguatges amb més avantatges que Java o .Net.

Aquests darrers dies estic llegint el llibre wxPython in Action de Robin Dunn i Noel Rappin. El llibre és un tutorial de com escriure aplicacions fent servir la llibreria wxPython i com fer servir cada component (widget) que la llibreria inclou.

En el que és la explicació de cada component i els exemples hi ha una gran quantitat de llistats de codi font i comentaris damunt aquests llistats. Això m'ha fet recordar el capítol en que Glass tracta la importància de poder llegir codi. Diu, i estic completament d'acord, que a programar no se n'aprèn sols coneixent la sintaxi del llenguatge de programació, sinó també escrivint programes i sobretot llegint codi que ha escrit altra gent, i que aquesta capacitat de llegir codi s'hauria de cultivar més a les universitats i escoles tècniques.

Sense aquesta capacitat de llegir codi d'altres també ens trobam que llegir tutorials com el de wxPython es fa pràcticament impossible, si no som capaços de llegir el codi, interpretar mentalment que fa i imaginar-nos la sortida, no ens queda més remei que picar el codi i executar-ho per aprendre, la qual cosa fa que l'avanç en el domini de la llibreria sigui molt més lent.

Ser capaç de llegir el codi d'un altre ens permet aprendre noves tècniques que potser no estan explicades en el llibre, normalment perquè no és el seu objectiu, i ens permet la lectura a llocs allunyats de l'ordinador: al sofà, a la fresca a la terrassa,...

El programari lliure ens permet llegir codi que ha fet altre gent, veure com funciona, aprendre noves tècniques o veure el que s'ha fet malament o maneres de millorar-ho. Aquesta capacitat és fonamental a l'hora d'aprendre el funcionament d'una nova llibreria, de fer inspeccions de codi abans de posar en test un programa, o a l'hora de depurar o modificar codi que ha fet una altra persona.

Les èpoques del programador solitari que ho feia tot han ja queden lluny. El més normal actualment és que els programes és desenvolupin en equip i la gent acostumada a llegir codi ho té molt més fàcil per a adaptar-se a la feina en equip.

Si una persona sols ha fet feina fent servir programari tancat no haurà tingut l'oportunitat d'aprendre el que significa poder veure codi de tercers i per tant la seva evolució com a programador serà menor que aquells que estan acostumats, bé per necessitat o bé per convicció, a llegir el codi font d'altres persones.

Com vaig sentir a dir a Ricardo Gali a una conferència de Bulma, el codi és una font en sí mateixa per emmagatzemar i transmetre coneixement.En els cas dels programadors això també es tradueix en possibilitat d'aprenentatge i amb minimitzar el nombre d'errors i tasques de depuració.

El clearsilver és una llibreria de plantilles que abans feia servir el Trac i que s'està substituint a favor de Genshi, una altra llibreria que segons la gent de Trac els causa molt menys problemes.

La cosa està, però, en que no es lleven les dependències fins a la versió 0.11 no s'eliminen les dependències de clearsilver i fins i tot en aquesta versió es mantindran les estructures necessàries per a que els plugins segueixin funcionant.

He pogut comprovar de primera mà el que es diu a la web de Trac, "clearsilver sucks", ja que amb Ubuntu i la versió 2.5 de Python no fa sino donar problemes, que sospit han acabat per tomar el servidor Apache 2 que tenim al webhosting virtual. En un primer moment he pensat que se'ns hauria tornat a oblidar el pagament, però no, tots els serveis eren vius llevat de l'Apache i als logs he vist un bon munt d'errors del tipus

   /usr/lib/python2.5/site-packages/trac/web/clearsilver.py:128: RuntimeWarning:

Python C API version mismatch for module neo_cgi: This Python has API version 1013, module neo_cgi has version 1012.

• Davallam el codi font: wget http://www.clearsilver.net/downloads/clearsilver-0.10.4.tar.gz
• Modificam els arxius config i config.in, cercam les línees que diuen python_version i i afegint la versió 2.5 al davant.
• Descomprimim el fitxer tar xvzf clearsilver-0.10.4.tar
• Davallam paquets adicionals però aquesta vegada per apt-get
  • sudo apt-get install zlib1g-dev
  • sudo apt-get install autoconf
  • sudo apt-get install python-dev
• Feim el configure: ./configure --disable-wdb --disable-compression --disable-perl --with-python=/usr/bin/python2.5
• I per acabar el sudo make install
• Com que la instal·lació no acaba d'anar fina convé copiar la llibreria generada sudo cp -i neo_cgi.so /usr/lib/python2.5/site-packages/neo_cgi.so per acabar de substituir la referència que hi havia de la llibreria anterior o fer un ellaç simbòlic cap a la nova instal·lació de clearsilver: sudo ln -s ./clearsilver-0.10.4-py2.5-linux-i686.egg/neo_cgi.so neo_cgi.so

Referències:

• http://trac.edgewall.org/wiki/TracForPython2.5
• https://bugs.launchpad.net/ubuntu/+source/clearsilver/+bug/114930
• http://trac.edgewall.org/wiki/ClearSilver
• https://launchpad.net/ubuntu/+source/clearsilver/+bug/86685

Titol: Software project survival guide Autor: Steve McConnell Editorial: Microsoft Press ISBN-13: 978-1-57231-621-8 Pàgines: 288

Sofware project survival guide és un llibre damunt la gestió de projectes en general, no entra a explicar cap metodologia concreta, sinó que és un conjunt de consells i llistes de coses a comprovar en els projectes, però sense mullar-se ni anar al detall.

Al contrari d'altres llibres de McConnell he de dir que aquest no està a l'alçada, pareix més un llibre d'aquells que es fan per pagar factures i que s'aprofita de la fama dels que l'han precedit.

Tot i això he ha coses aprofitables: alguns "survival checks", una mena de llistat de coses a tenir en compte o a fer per dur endavant el projecte, i és un recordatori del cicle de vida d'un projecte.

L'estil tampoc és el que acostuma McConnell, molt més amè de llegir. Aquest m'ha costat acabar-ho, ja que li passaven per davant tots els altres llibres que he anat comprant aquesta temporada.

En el que fa a l'edició, el llibre té una edició amb una tipografia de cos dotze amb molt de marge per tot i amb un doble espai generós. Amb una altra tipus d'edició el llibre no passaria del centenar de pàgines.

En definitiva, si us ho regalen o el trobau de segona ma agafeu-lo, però no val la trentena d'euros que costà.

Trobar bona gent és difícil i trobar-la que a més es pugui integrar en un equip ja format encara ho és més. A les respostes d'anuncis de feina s'hi pot presentar molta gent i en poques preguntes sovint s'ha d'intentar esbrinar si la persona que tens al davant serà bona tècnicament i a la vegada la seva manera d'entendre la feina serà per l'estil de la que hi a al grup.

Encara que soni molt a tòpic hi ha una sèrie de regles heurístiques que quan parlam de programació web ajuden a fer-se una idea d'ambdues coses:

• Adreça de correu amb domini propi : suma un punt. Per mi vol dir que al manco hi ha una preocupació per cercar-se la vida i potser haver donat d'alta un domini. Tenir un domini implica que també es pot cotorrejar abans de la selecció i veure quins temes preocupen al possible candidat o candidata.
• Adreça de correu amb Hotmail: resta dos punts. Sovint també vol dir que estàs engantxa al messenger i/o que no ets capaç de diferenciar el tenir un correu per usos lúdics d'un per usos professionals. Serveix per a diferenciar la gent que el primer que intentarà fer és posar-se el Messenger.
• Edició d'HTML. Si el sols es sap fer servir el Dreamweaver resta de cop 2 punts. Implica que d'entrada es tendran problemes quan es tracti de modificar planes webs fetes a troços, pràctica habitual en la programació web. Si utilitza un editor amb resaltat de sintaxi suma un, si a més sap fer servi el vi/vim suma dos punts. Si no ha fet mai una plana web resta cinc punts de cop.
• Coneixements de CSS. Si ha maquetat pàgines amb CSS i sap perquè ho ha fet suma 2 punts. Si no sap perquè ho ha fet sols en suma un. Si no sap què és resta un punt. Tenir coneixements de CSS ajuda a saber el que es podrà fer en la pàgina.
• Coneixements de Javascript. Si els sap fer servir mitjanament suma un punt, si a més coneix alguna llibreries de les típiques suma un altre punt. Si sols coneix el que posa el Dreamweaver lleva un punt. Tot es pot aprendre, però si un ja té experiència en Javascript vol dir que realment ha programat per la web. Si a més abans ha dit que utilitzava un editor "per programadors" començarà a agradar-me força.
• Si sap què és l'arbre DOM suma un punt. Si no ho sap i ha dit que ha manejat força Javascript ens haurem de plantejar sèriament si ha està decorant el currículum.
• Si sap què són els estàndards W3C suma un punt.
• Si sap que és un sistema de control de versions suma un punt, si a més l'ha fet servir suma un punt més.
• Utilitzar Linux suma dos punts. Per una part vol dir que encaixarà millor en el grup, però objectivament vol dir que serà capaç de modificar una plana que no està al servidor local, estarà acostumant a que els noms dels arxius són diferents en majúscules i en minúscules, sabrà què és l'UTF-8, etc. I sobretot demostra ganes de fer coses i de no conformar-se amb el que fa la gran majoria.
• Utilitzar Firefox com a eina de desenvolupament. Suma un punt. En suma un altre si coneix dos plugins indispensables per al desenvolupament web.
• Conèixer un llenguatge de programació d'script suma un punt. Si aquest es Python o Perl en suma un altra. PHP o Ruby no puntuen més. Un perquè a un que fa programació web se li suposa un mínim coneixement de PHP i Ruby perquè no es pot distingir de si es fa per moda o per convenciment.
• Conèixer el patró MVC i saber-ho explicar suma un punt. El patró MVC s'ha convertit en omnipresent per la web i conèixer-lo i fer-ho servir indica que es una formació en programar pensant en la separació entre capes.
• Conèixer SQL suma un punt. No fer-ho en resta un. No puc concebre que algú faci webs dinàmiques i no tengui idea d'SQL.
• Conèixer els bastiments i llibreries utilitzades a l'empresa suma dos punts.
• Ser membre actiu de Bulma o algun LUG suma un punt. Indica que el candidat s'implica en el que fa i contribueix amb les seves aportacions.

Hem de dir que d'entrada el possible candidat ha de conèixer el bàsic que se li demana, és a dir, si l'oferta és per programador Java-J2ee, si ja no es sap cap de les dues coses doncs el més probable és que el seu currículum ja no passi pel filtre de RRHH. Si ho fa llavors ens trobam davant un currículum que pot ser vàlid o estar especialment decorat per l'ocasió.

Un currículum amb una puntuació d'entre 17 i 20 és algú que s'ho paga entrevistar amb més profunditat. Entre 13 i 16 convé fer-hi una ullada però no hi ha massa possibilitats així d'entrada, i si és menys que aquest valor doncs potser és millor no perdre-hi més temps.

Tant les opcions com les valoracions són elegides ad-hoc sabent d'entrada el tipus de gent que m'agrada i que potser encaixarà bé en el grup, empreses i grups distints poden tenir valoracions distintes. Segurament una persona amb una puntuació de 20 no encaixarà en un ambient poc dinàmic i que no tengui capacitat d'innovació.

N'Enrique Dans es demana a un article ¿Alguien ha visto un programador? i en Ricardo Gali li diu que yo he vistos unos pocos. Particularment he de dir que jo sí que n'he vists de programadors i de bons, però com tot el que és excepcional un bé escàs i en el cas dels programadors he d'afegir que és un bé poc valorat.

A l'article d'Enrique Dans ens diu que el desenvolupament tecnològic d'Espanya s'està alentint perquè no hi ha bons programadors de PHP, Java, Python, Perl o RoR per a dur a terme els projectes d'Internet. Ho sento, no hi puc estar d'acord, els projectes d'Internet a més de pels programes i els programadors tenen un factor limitador que és el cost del hosting i de l'ampla de banda. Si comparam el que costa hostejar un projecte ambiciós a Espanya i ho comparam amb el que costa fer-ho a altres indrets veurem que el programador Espanyol ja no es planteja desenvolupar perquè tanmateix ja sap que les seves possibilitats de créixer són molt limitades, ja que ben aviat els costs pujaran per damunt dels guanys.

L'ampla de banda de les connexions domèstiques tampoc ajuda, la velocitat de pujada de les connexions ADSL fa rialles i el cost de més velocitat és prohibitiu. Sempre ens queda la solució de fer el hosting a països més barats, però això ja està penalitzant la velocitat d'accés si el negoci ho vols fer per començar al mercat Espanyol i perds el control que te donaria tenir els programes al teu propi datacenter, encara que aquest pugui ser tan petit com un servidor o dos col·locat al destpatx de casa. En aquest moments i amb les connexions actuals l'inversió necessària per tenir un grapat de servidors dedicats amb prou ampla de banda a Espanya, fa que els costs fixes siguin tan alts que cal pensar-s'ho molt a l'hora de montar un negoci tecnològic a l'estil del que ens tenen acostumats emprenedors americans.

Així doncs, l'endarreriment en noves tecnologies no és tant per l'absència de bons programadors, sinó que tot el teixit tecnològic que hi ha a la nostra societat o l'absència del mateix, fa que encara que aquests hi siguin, no es donin les condicions per a que prosperin. Empreses poc donades a la innovació, departaments d'I+D+I inexistents, costs de les comunicacions prohibitius, empreses que donen més importància a les aparences, a l'estar que al fer i una gran mancança de cultura informàtica en el que fa al desenvolupament de programari i a la gestió d'equips tècnics són tant o més responsables de l'endarreriment que patim.

Per una altra banda quan parlam de noves tecnologies al perfil del bon programador, del tècnic se li ha d'afegir la de la capacitat de treball en equip. Avui en dia i en projectes d'Internet és impensable dur a terme alguna cosa mitjanament grossa sense la col·laboració de programadors, dissenyadors i tècnics de sistemes. Trobar perfils compatibles ajuda moltíssim (de 3 a 10 vegades) al projecte i augmenta les possibilitat d'èxit, i això xoca amb processos de selecció basats en la força bruta, és a dir, en un "pongame aquí 20 tios que ...", el nombre no és tan important com la capacitat d'autocoordinació, la iniciativa i la capacitat tant individual com del conjunt.

Potser falten bons programadors, però també falten i molt empreses que vulguin bons programadors, fins i tot empreses que vulguin un equip de bons programadors i que entenguin el perquè una vegada un equip s'ha format i funciona s'ha d'intentar mantenir i evolucionar.

La tecnologia i el programari s'ha convertit en una part fonamental de les empreses, però la figura del programador enlloc d'estar cuidada està denostada. Els cursos per fascicles de "programar es fácil" no han ajudat gens a la valoració de la professió. La capacitat de fer mals programes és infinita, la capacitat de fer-los bé està sols a l'abast de la gent amb passió per la seva professió, una passió que el motiva i que el duu cada dia a superar-se, a fer millor les coses, a aprendre.

Sovint però el que trobam és el programador que programa per menjar. És l'antítesi del tipus de gent que fa que les tecnologies de la informació passin de les idees als fets. Programar per menjar implica dedicar-se a programar sols perquè és una feina on no et banyes quan plou, on un fa el que toca i fins a on li han dit i res més, sense plantejar-se si se podria fer millor, sense cercar avançar sinó tot el contrari, procurant que la feina que fa duri molt per tal de no haver d'aprendre coses noves.

Els programadors dels que parlen Enrique i Ricardo no programen per menjar, programen per viure. L'aspecte econòmic és important per viure però encara que tinguéssin que dedicar-se a altres feines per subsistir programarien.

Un bon programador ha de ser també inconformista, crític i perquè no un tant freaky. Crec que tot va lligat, l'inconformisme ens duu a cercar altres maneres de fer les coses, a pensar alternatives. El pensament crític ens ajuda a millorar i el freakisme ens fa part d'un club selecte, forma lligams i fa equip.

Bons programadors? En conec un grapat, però on són les empreses que tenen les condicions per a que aquests desenvolupin tot el seu potencial?

Alguns professionals de les TI no deixen de sorprende'm, són capaços de contradir-se una frase després de l'anterior, intentant justificar l'injustificable.

L'altra dia algú es queixava del complexe i costós que resulta fer les actualitzacions dels productes d'Oracle, que si has de fer venir una múnia de consultors, que si les dependències entre productes són tan complexes que quan actualitzes un producte has d'anar molt alerta amb com afecta a la resta de productes de la companyia, etc.

Aquí a mi no me queda més remei que fer paleses les contradiccions: si és tan complexe de gestionar, si te ferma tant al proveïdor, com és que hi ha gent que encara s'entesta en fer nous desenvolupaments en una tecnologia que te ferma de manera que les simples actualitzacions de versions són un maldecap i amb un costs que són difícils de predir.

L'excusa de que el denvolupament amb Forms i PLs és més ràpid s'enfonsen ràpidament davant mètriques que ens diuen que el nombre de línies per punt funció són comparables en Forms o en Html (42 i 43 línees de codi per punt funció respectivament) i per la part presentació, de 46 de PL/SQL als 35 de llenguatges de l'estil d'Smalltalk (Python per exemple). [1] i això sense considerar aspectes que afecten a la productivitat com la facilitat de depurar el codi, de fer feina en grup, o de fer tests d'unitat.

Davant això, pareix que la raó fonamental de triar productes d'una companyia concreta com els d'Oracle, no són de menor cost o major facilitat de desenvolupament, sinó que pareix que són que així el responsable del projecte no té que pensar. No hi ha possibilitat d'equivocar-se a l'hora de triar l'arquitectura o els components perquè no hi ha arquitectura o components per elegir. Sols tenim el que els senyors d'Oracle han decidit que podem tenir, independentment de les necessitats reals que podem tenir. Això se diu com a FUD davant les eines i bastiments de programari lliure, on abans de començar el projecte s'ha de definir l'arquitectura que es farà servir i triar els components més adients per la feina.

A mi que algú em digui que elegeix una eina o una altra perquè així no té que pensar em dóna angúnia. La responsabilitat del cap de projecte en primer terme i del responsable de IT en darrer terme és assegurar-se que té el millor equip i la millor tecnologia a l'abast del negoci, de manera que es puguin respondre a les necessitats del negoci amb rapidesa. S'ha d'estar pendent tant de l'evolució del negoci com de les tecnologies informàtiques que poden fer que la resposta del departament d'IT pugui seguir l'empresa.

Que hi pugui haver gent a una empresa que en senti còmoda amb una solució que a mig o llarg plaç sabem que donarà problemes, que té molts costs ocults d'actualització i administració, que se senti còmoda amb el no pienses, nosotros pensamos por ti explica perquè empreses més petites, però amb gent que no té por a pensar cada cop més s'estan enduent més negoci o posant en marxa negocis innovadors. En el moment que els negocis comencin a adonar-se que necessiten innovació per avançar, quan comencis a mirar el perquè negocis més petits tenen més clients i fan més caixa amb un costs menors i se n'adonin de que el no pensar no és una alternativa podem viure un vertader d'altabaix a alguns departaments informàtics.

Comencem a pensar, comencem a voler pensar, demà pot ser massa tard.

[1] Font: http://www.qsm.com/FPGearing.html

Fa uns dies que estic de vacances i estic aprofitant per tancar algunes coses que tenia a mig començar. Una d'elles era la publicació d'un article damunt l'estimació de projectes de programari fent servir una tècnica que es basa en els casos d'ús que es fan a l'etapa inicial del projecte.

Aquesta tècnica és molt senzilla de fer anar i resulta sorprenentment acurada una vegada hem ajustat alguns paràmetres que depenen de la nostra organització.

Per fer-la anar basta un escriure els casos d´ús, cosa que tanmateix hem de fer si volem fer una estimació real de qualsevol projecte que es desenvolupi en programació orientada a objectes, i a partir d'aquí aplicar les regles d'estimació dins un petit full de càlcul.

Per projectes petits (de més de 10.000 línies de codi, però) i mitjans les estimacions obtingudes són tan bones com les d'un estimador expert i comparables a les que s'obtenen amb programari tancat i privatiu d'estimació de projectes.

L'article de Bulma és el 2376. Pos els enllaços directes al pdf amb l'article i les plantilles.

• Estimació de projectes de programari mitjançant casos d'ús
• Plantilla pel càlcul
• Exemple de càlcul i estimació

En la literatura de gestió de projectes és habitual trobar-nos amb el concepte d'hores-home per expressar la unitat de mesura de projectres, com a una unitat que expressa el temps necessari per a desenvolupar un projecte. Així 100 hores-home indica que el cost de projecte seria equivalent al de 100 hores d'un sol programador.

El problema de les hores-home és que es presten a confusió quan el nombre d'hores-home passa cap a gent no tècnica, que té que aprovar un pressupost o dir en quant de temps s'ha de fer un projecte.

a) Pot donar a entendre que les hores de programació són intercanviables. Es a dir, 100 hores-home per fer un programa poden ser fetes per 100 programadors treballant una hora, com per 10 programadors treballant deu hores, com per dos únics programadors que s'hi dediquen 50 hores.

b) Suposa que totes les hores de treball són efectives. És a dir, suposa que un programador és capaç de ser productiu des de el mateix segon que es posa a pensar en el programa.

Per evitar el primer problema el nombre d'hores-home ha d'anar acompanyat amb temps mínim de realització i el temps més probable, de manera que es pugui veure que l'augment del nombre de programdors a l'equip no implica necessàriament que es reduexi el temps necessari per entregar el projecte, és a dir, que quedi molt clar que hi ha un temps mínim per sota del qual no és possible entregar el projecte.

Molt més problemàtic és explicar el tema de la no intercanviabilitat de la gent. El més normal és explicar-ho en termes de coses que el nostre interlocutor ja conegui, indicant que hi ha gent especialista en cada cosa i que no es pot substituir fàcilment una gent per una altra. Comparar programadors amb metges és força efectiu, podem explicar que quan et fa mal un queixal no vas al proctòleg sinó al dentista. Els dos poden ser metges i molt qualificats, però cada un té la seva especialitat.

Atacar el segon supòsit implica no presentar la valoració del project en termes d'hores-home, convé anar cercant una altra unitat de mesura que ens permeti expressar millor el que és una hora de programació efectiva.

El concepte d'hores efectives està tractat molt bé al Peopleware, on es dedica tot un capítol complet al tema de les hores de treball ininterromput vers les hores de permanència a l'oficina. És el que anomena E-Factor, i ens dona una idea del treball que es perd per no tenir un ambient de feina que permeti tenir prou hores sense interrupcions.

Quan feim una estimació en termes d'hores-home poques vegades es considera la correcció que ve de l'E-Factor, de fet potser ni tan sols se'ns sap el valor, ja que ningú s'ho ha plantejat mai, sols se sap que els projectes es retràssen i no se sap ben bé perquè.

Per una altra banda, la metodologia de l'Extreme Programing proposa que les valoracions de les tasques es facin en termes d'Ideal Engineering Hours (IEH). És a dir, que les valoracions s'expressin en termes de temps sense interrupcions necessari per a completar dita tasca.

Particularment m'agrada molt la idea de tenir una unitat per expressar la dedicació necessària per fer un programa que implícitament té en compte que la feina es pot allargar més o menys en funció de les condicions laborals i de les interrupcions que es tinguin.

Fent servir les IEH com a unitat de valoració en lloc de les habituals d'hores-home estam transmetent la idea de que el desenvolupament de programari és una tasca on les interrupcions tenen un impacte molt gran en la productivitat dels programadors i per tant en el cost del projecte.

De retruc potser algú es demanarà el perquè d'aquest canvi i tal volta es plantegi poder calcular l'E-Factor.

Amb tot això ara quedaria discutir quina és la validesa de les estimacions de programari, és a dir, s'han de realitzar estimacions per saber el cost aproximat del projecte, però ens queda per saber com n'és de bona aquesta estimació o si ha d'anar lligada a que hi hagi una especificació completa del projecte, com si de fer un edifici es tractàs. Quan parlam de programari la comparança amb la construcció d'un edifici ens enfonsa la metàfora, però bé, això són figues d'un altre paner i ja miraré de parlar-ne més endavant.

Ara per ara potser alguns ja us estigueu plantejant presentar les vostres properes estimacions en termes d'IEH o anar calculant el vostre E-Factor particular, si ho feis m'agradaria conèixer quin és, que els estudis de productivitat en programari són més aviat rars en aquestes contrades i potser entre tots puguem treure'n alguna conclusió.