El tamany sí importa

Escrit per Aaloy a 18 de February , 2007 a les 3:27 p.m.

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.

Enllaços citats

• llei de Moore

3 comentaris, 0 trackbacks (URL) , Tags: Informàtica

Lo que dius és vera i, a més, els nombres són bons.

Però... estàs tenint en compte que els programadors són perfectes, són ens automàtics que arriben puntuals, s'asseuen i produeixen una determinada quantitat de codi funcional en el mateix periode de temps.

Ni que dir cal que això no és cert. Les persones mengen, van al lavabo, fumen, beuen... És més, ja saps que la productivitat de dues persones diferents és diferent en dies diferents. No és lo mateix un dilluns d'un fadrí jove que un dilluns d'un casat amb al·lots. A l'inrevés passa amb el divendres.

A jo m'agrada més veure-ho com a despeses del projecte: Quina és la part proporcional del total del projecte destinada a despeses en maquinari i llicències? A partir d'aquesta dada i del nombre de projectes que s'enllesteixen a l'any es pot jugar amb els nombres (miserables, en comparació, per cert) i determinar si l'organització se pot gastar 1200€ a l'any en maquinari amb 4 desenvolupadors que poden generar un aplicatiu de 300 funcionalitats cada un en un any.

Quant val un aplicatiu de 300 funcionalitats i un any/home? Si l'empresari no vol veure que pot perfectament baratar el maquinari cada 24 mesos és perquè, senzillament, no li dóna la gana.

També hi ha picapedrers que fan feina amb les eines rovellades i rompudes.

Els programadors/desenvolupadors/fabricants de programari som uns incompresos :-)

Paco, no estic suposant que la gent sigui perfecta, el que dic, és que invertir en eines bones té incidència en la productivitat i que té més cost no fer-ho que fer-ho. Partim de que en mitja tothom fa el mateix, llevat de mals de panxa, clar! A partir d'aquí hem de començar a veure i trobar maneres d'augmentar la productivitat que directament impliquen un estalvi per l'empresa.

Quan a les xifres que estam donant les multiplicam per 10 o per 20, per a un projecte concret, veim que tenir bons equips implica un estalvi considerable en el cost final del projecte. 30.000 Eur en un projecte pot ser el límit entre que l'aprovin o no.

Si anam cap a veure si l'organització es pot gastar o no, anam cap al tema dels 4 anys d'amortització. El que es tracta és tenir els números fets. El cost REAL d'un programador no és sols el seu sou, és també el cost del seu lloc de feina, la part proporcional del servei de neteja, la calefacció, etc. Als càlculs estic anant a mínims, però no són gens rars casos en que el cost pugi estar entre els 250 i els 300 Eur per persona, així que si afinam més per empreses concretes ens podríem trobar amb estalvis del doble o el triple del que estic dient.

L'efecte de màquines millors, de pantalles més grans són factors de segon o potser tercer ordre, però que té implicacions damunt factor de primer ordre: la gent.

Fer comprendre aquest tipus de coses, poder-les argumentar fa que puguem passar del "programador que ja vol una màquina més potent per jugar" al programador que "ha de tenir la millor màquina perquè si no perdem doblers". Al final la informàtica empresarial va d'això, de guanyar pasta.

M’ha encantat l’argument de passar de llenguatges com Java a dinàmics ^_^

En tot cas és el que ja comentava un altre dia: el tenir a la gent contenta, fer que es senti còmode fent feina i tenir bon material és un gran punt a favor de l’èxit del projecte. I hem de reconeixer que a tots ens encanta tenir màquines noves i potents!