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ó.