L'OpenOffice duu un complet editor d'equacions matemàtiques, motl útil quan volem escriure fórmules complexes dins el nostre document.

L'editor segueix un poc la filosofia de LaTex, és a dir, encara que té ajudes gràfiques es suposa que està pensat per gent que escriu moltes fórmules, i per tant, la interfície d'entrada és el text.

Com que a mi m'agrada molt LaTex per escriure documents llargs (tenguin o no tenguin fórmules) trob aquesta manera d'allò més natural, però com que no escric fórmules cada dia, doncs a vegades no record massa bé com es feia alguna cosa.

En concret sempre he d'anar a cercar com es fa per posar una sola clau a un sistema d'equacions. Cercant per Google, he trobat aquest enllaç que esper que també pugui ser d'utilitat als asidus de l'OpenOffice Math:

http://es.tldp.org/Manuales-LuCAS/doc-manual-OOMath/Math.pdf

Una fantàstica traducció del manual en format pdf i que des de ja figura dins els meus pdf preferits, junt amb la traducció de "In the Beginning was the Command Line" de Neal Stephenson

http://biblioweb.sindominio.net/telematica/command_es/command_es.pdf

Fan un anunci per la tele, apareix un home netejant una façana, apareix algú que es fa neta la boca amb un elixir bucal. L'elixir és molt potent, se veu, quan ho deixa anar per les canonades d'aigua bruta es veu com va baixant com una bomba,... Després una canonada d'aigua neta explota com per l'efecte de l'elixir i acaba de fer neta la façana. Tot molt gràfic, tot molt normal, llevat que no és correcte. Si explota la canonada hauria de ser la d'aigua bruta i l'home de la neteja no crec que estigués molt content com un sortidor d'aigua fecal pega per la façana.

Sorprenentment veim l'anunci i ho trobam d'allò més normal. Exagerat, potser, però és cosa de la publicitat. Llevat d'això tot ens pareix correcta, la nostra intuïció ens ha fallat.

Si això ens passa en coses que suposadament dominam, que vivim cada dia, quan ens situam en un entorn menys habitual, com el món del programari i la programació, la intuïció encara ens poc jugar més males passades. La intuïció ens diu que posar més gent a un projecte ha de fer que el projecte vaig més ràpid, però la realitat és que pot fer que el projecte no avanci amb la velocitat esperada. Això es deu a que afegir gent al projecte no implica un augment lineal de la productivitat, sinó que hi pot haver casos en que la productivitat fins i tot disminueixi.

Un projecte amb molta gent necessita de més planificació, d'una comunicació fluïda entre els seus components, i aquesta comunicació i coordinació fa que sigui necessari dedicar-hi recurssos que d'altra manera es dedicarien integrament al projecte, ja que en un equip més petit tendríem menys necessitat de comunicació formal.

Un altre dels factors que influeix és el que s'anomena tendència a la mitja. Si l'equip és petit, entre 3 i 10 persones és probable que puguem tenir un equip d'elit, però si augmenta el nombre de gent la tendència a la mitja suposa que sols podrem completar l'equip amb gent prou bona, però potser no tan productiva com la d'un equip especialment seleccionat. En aquest casos, la intuïció que ens diria que s'ha de fer més via també ens ha fallat, podem arribar anar més a poc a poc. Això no vol dir, però que no hi hagi avanç a mig termini, sinó que a curt termini podem esperar un retràs considerable, mentre les vies de comunicació es consoliden i tots els components es van adaptant, i tot i així, l'augment de components de l'equip no serà lineal: comunicació, formalització més acurada de procediments, més necessitat de control fi coordinació espenyen aquesta linealitat. I quan consideram l'equip del projecte no hem de pensar sols en programació, hem de pensar en tota la gent implicada: testers, managers, usuaris avançats. Quanta més gent més probabilitats que la tendència a la mitja jugui en la nostra contra.

Tot el que té a veure amb la tecnologia ha avançat molt ràpid, si amb conses que ja coneixem les nostres suposicions són incorrectes, hem d'estar previnguts de que en tot allò que fa referència amb la tecnologia encar ho poden ser més: escriure programes no és el mateix que escriure una carta, un ordinador no és una màquina d'escriure, una pantalla no és una fulla de paper, les webs no són equivalents a una publicació de paper, el que nosaltres considerem bo no te per què ser-ho pels nostres usuaris, d'aquí que es tenguin que fer proves d'usabilitat. Si es pot mesurar mesurem-ho, potser la nostra intuïció ens està fallant.

En moltes empreses per procediment es canvien tots els ordenadors cada quatre anys, quan el valor de l'equip s'ha amortitzat totalment.

Aquesta no és una mala pràctica pels equips d'oficina, però el café para todos és molt perjudicial en entorns de desenvolupament, on es vol aconseguir un ratio de productivitat màxima.

Anem a pams, suposarem que el cost d'un equip nou de trinca és de 600 € + IVA, en aquests moments estaríem parlant d'un Core Duo 2,13 GHz amb 2 Gb de RAM, és a dir una màquina prou potent com per poder fer feina amb entorns devoradors de màquina com la combinació Eclipse+Java.

Ens plantejam quan hem de renovar aquestes máquines, hem d'esperar als quatre anys o convé renovar-les abans? Podem fer una sèrie d'estimacions bàsiques que ens ajudaran a respondre a aquesta pregunta.

La feina d'un programador té un cicle d'escriptura de codi, compilació, proves i depuració. Si feim servir llenguatges interpretats de l'estil de Python, Ruby o PHP aquest cicle canvia, però per ara centrem-nos en lleguatges més clàssics com .Net, Java o C++. Aquest cicle, i per exemple el desplegament de l'aplicació en un servidor d'aplicacions local com Tomcat o JBoss, implica que per a cada prova que es fa es perdren entre 3 i 6 minuts per prova (compilació o generació dels bytecodes, còpia al servidor, desplegament de l'aplicació, inici del navegador i començament de les proves).

Suposem també un sou brut d'un programador de 24.000 Eur anuals, i que hi ha 223 dies efectius de fiena, és a dir, el cost per diar de programador sols en sous és de 107,62 Eur.

Considerarem vàlida la llei de Moore i considerarem que als 18 mesos de fer la nostra compra, podem comprar un nou ordinador, més o manco pel mateix preu que dobla les capacitats de procés del nostre ordinador actual, amb la qual cosa el temps d'arrancada és pot reduïr a la meitat. Serem conservadors i donarem un marge de 2 anys.

Amb això tendríem:

• Valor pendent d'amortitzar: 300 Eur
• Temps mort per prova 3 - 6 minuts
• Nombre de proves per dia : 10
• Sou per dia del programador: 107,62 Eur
• Dies útils de programació : 223

Ara ens plantejam canviar la màquina, està clar que la màquina als dos anys no està amortitzada, tot i això, ens podem plantejar donar de baixa la màquina i que l'operació encara sigui molt rentable per l'empresa.

Si consideram una pèrdua de 3 minuts per prova tindríem que el temps anual en hores perdut és de 111,5 hores, és a dir 13,94 dies. Si anam als 6 minuts per prova, resulta que pràcticament un mes de feina es perd esperant a que la màquina estigui a punt per provar.

Canviant la màquina per reduïr el temps d'espera suposa un estalvi d'entre 1.500 Eur i 3.000 Eur l'any per programador si suposam que podem col·locar la màquina antiga o d'entre 450 Eur i 1.200 Eur si directament la regalam.

És a dir, canviar d'equip cada 2 anys per disminuir el temps d'espera entre compilació i proves, pels temps que estam manejant és justifica completament.

A més, però tenim un altra benefici tangible: augmenten les hores dedicades al projecte i disminueix la frustració que suposa tenir que esperar un parell de minuts entre que vols començar les proves i aquestes comencen.

Si no canviam màquines, el que tenim són directament pèrdues, per una part perquè deixam de tenir l'estalvi produït per la inversió que no hem fet, però a més, hem de tenir en compte que amb els anys les aplicacions tendeixen a fer-se més grans, més complexes i per tant ens podem trobar sempre en l'escala superior de temps d'espera.

Una manera de lluitar amb aquest efecte és anar cap a llenguatges i entorns que no tenguin aquests teps d'espera, és a dir, desenvolupar amb llenguatges dinàmics com Python, PHP o Ruby. En aquests casos el temp d'espera es redueix pràcticament a zero, i tendriem ja d'entrada tot l'estalvi, és a dir, el pas de desenvolupar en Java cap a Python, per exemple, suposa un estalvi sols en temps d'espera d'entre 1.500 i 3.000 Eur anuals per programador, deixant a banda la diferència de productivitat en termes de línees de codi entre un i altre llenguatge.

Un altre factor d'estalvi, encara que no tan important com el del llenguatge com el processador, ho podem trobar en les pantalles. Tenir una pantalla gran o dues pantalles pel desenvolupament, fa que el programador no té que anar canviant de finestra o que els canvis que fa són mínims. Un estalvi de 2 minuts al dia per aquest concepte implica un estalvi de 100 Eur anuals, si tenim en compte que l'amortització d'una pantalla de 20" és també d'uns 100 Eur anuals, tendriem que arribam a la partiat, al break event, però millorant sobremanera l'entorn de desenvolupament del nostre personal, i per tant la satisfacció en que es fa la feina, i la satisfacció i motivació del personal, són efectes de primer ordre en la productivitat.

En poques paraules, equips més grans, més potents, pantalles amb més resolució, tenen un impacte quantificable en el desenvolupament web. Canviar equips abans de que estiguin amortitzats pot tenir un impacte significatiu en la compta de resultats d'un departament informàtic, tant amb el que suposa d'hores de feina estalviades, com per l'augment de motivació del personal que hi fa feina.

Quan es parla de metodologies de desenvolupament ràpid d'aplicacions segurament sentirem parlar d'scrum, RUP, XP com a més rellevants. Hi ha però una altra metodologia anomenada ASDM o 3UI [1], que intentaré explicar a continuació: Aquesta metodologia es caracteritza per la presència d'un stakeholder[2]  quen no sab massa bé què vol, però  vol lo mateix que el que té el veinat, però millor, més barat, més ràpid, que sigui exactament igual però que no s'hi sembli. Això és condició necessària però no imprescindible. Per a trobar-nos davant un projecte ASDM és important també que l'stakeholder tengui un esperit comercial fort, capaç de fer promeses que obliguen a tercers amb plaços que no tenen cap base. Això no implica que tots els projectes promoguts per comercials siguin 3UI, per a ser-ho és necessàri que el comercial no tengui ni la més petita idea del que costa fer el que ha promés i que els seus objectius no depenguin dels beneficis de l'empresa sinó dels clients captats, o de la venda immediata realitzada. Els projectes ASDM també es caracteritzen per tenir com a pla de negoci un powerpoint on ningú sap ben bé d'on han sortit les xifres que s'hi presenten, però amb uns dibuixets molt divertits. La condició imprecindible per l'èxit sol ser el projecte que s'ha de-fer-per-demà-i-deixau-ho-tot, sense tenir en compte si el projecte es viable en termes de temps o economia. Cal diferenciar aquests tipus de projectes dels projectes deathmarch. Els segons responen a una planificació acurada, encara que amb unes limitacions de temps que els fan d'alt risc. Els primers es caracteritzen per no tenir cap pla concret ni molt manco una planificació, correccions i variacions del projecte cada cinc minuts, canvis de direcció i especificacions cada dos dies i molta primma donna demanant coses. Més tard o més prest són projectes que acaben malament, bé perquè el projecte en sí neix mort [3] o perquè l'esforç requerit per dur-ho a terme fa que es deixin de banda coses del dia a dia i altres projectes que fins a les hores manteníen l'empresa. És una aposta amb un revòlver amb 5 bales i dues tirades consecutives, potser que la primera surti bé, però no sobrevius a la segona.

---

[1] A Salt De Mata o ui-ui-ui, interjecció emprada pels programadors quan veuen el que se'ls hi ve damunt[2] El qui paga [3] I dic projecte per dir alguna cosa

Fa uns dies trespams.com va i ve. He anat obrint tiquets al hostingaire, livehost.net sense massa èxit. Obria el ticket i després d'una estona més o menys llarga tornava a estar actiu. Avui també ha caigut. He obert tickets i una vegada més sense resposta, no sé si perquè el compte que tenia a wandoo ha acabat de morir o què, però el cert és que feia unes quantes hores que els havia obert i el lloc seguia abaix, ni per ssh hi podia accedir. Al final he enviat un e-mail a la gent de compres de Livehost i curiosament sols després d'uns minuts ja tenia la resposta d'un tal Zak que me deia que havia tancat el lloc perquè un script meu li omplia el /tmp del servidor i que com que no li contestava el mail, doncs tancat!. El suport a Livehost ja no és el que era. Abans de fer això l'anyorat Tremain hagués enviat també e-mail a les altres comptes del domini. El més greu és que no m'ha sabut dir quin script dona els problemes i al meu compte sols hi tenc actualment aplicacions que estan al Fantastico del propi hostingaire. Fins ara no havia tingut cap problema amb el nou propietari de Livehost i potser durant alguns mesos els concediré encara el benefici del dubte, però l'explicació de que és un script que els omple els temporals sense saber dir-me res mes no m'agrada gens. Per si un cas serà cosa d'anar augmentant la freqüència dels backups...