Joel on Software   Joel i el programari

Altres articles de "Joel on Software" en català

Altres articles de "Joel on Software" en anglès

Envia un correu a l’autor (només en anglès)

Has sentit a parlar de SEMA? És un sistema força esotèric per mesurar com és de bo un equip de programadors. No, espera! No segueixis aquest enllaç! Et faran falta uns sis anys només per entendre tot allò. Així doncs, he creat el meu propi test per mesurar la qualitat d'un equip que fa programari. El més interessant és que es pot fer en 3 minuts. Amb tot el temps que estalviaràs, pots estudiar Medicina.

La part bona del Test de Joel és que és fàcil respondre ràpidament sí o un no a cada pregunta. No has de calcular les línies-de-codi-per-dia o la mitjana-de-bugs-per-punt-d’inflexió. Dóna al teu equip 1 punt per cada resposta afirmativa. La torna del Test de Joel és que realment no has d’utilitzar-lo per garantir que el teu software de control d’una central nuclear és segur.

Una puntuació de 12 és perfecta, 11 és tolerable, però 10 o menys i tens problemes seriosos. La veritat és que la majoria d’organitzacions que fan programari van tirant amb una puntuació de 2 o 3, i necessiten molta ajuda, perquè empreses com Microsoft estan permanentment a 12.

Per descomptat, aquests no són els únics factors que determinen l’èxit o el fracàs; en particular, si tens un gran equip de software treballant en un producte que ningú no vol, bé, ningú no el voldrà de totes maneres. I és possible imaginar un equip de "cow-boys" que no fa res d’això i tot i així aconsegueix produir programes increïbles que canvien el món. Però, amb tot el demés constant, si aconsegueixes aquests 12 punts, tens un equip disciplinat que pot lliurar un producte consistentment.

1. Utilitzes un sistema de control de versions?
He utilitzat paquets de control de versions, i he utilitzat CVS, que és gratuït, i deixa’m dir-te una cosa: CVS ja va bé. Però si no tens control de versions, perdràs l’oremus intentant que els programadors treballin junts. Els programadors no tenen manera de saber el que han fet els demés. Els errors no es poden desfer fàcilment. L’altra cosa bona dels sistemes de control de versions és que el codi font en si mateix és copiat al disc dur de cada programador – mai no he sentit parlar d’un projecte que utilitzant control de versions, hagi perdut una gran quantitat de codi.

2. Pots fer una recompilació en un sol pas?
Amb això vull dir: quants passos fan falta per tenir una versió per lliurar des de l’última situació del codi font? En els equips bons, hi ha un únic script que pots executar i que partint de zero obté el codi, en recompila cada línia, construeix els EXEs, en totes les seves versions, idiomes, i combinacions d’ #ifdef, crea el programa d’instal·lació, i crea el medi de distribució final – format CDROM, pàgina web de descàrrega, o el que sigui.

Si el procés requereix més d’un pas, és font d’errors. I quan estàs a punt de lliurar, vols tenir un cicle molt ràpid de corregir el "darrer" error, fer els EXEs finals, etc. Si fan falta 20 passos per compilar el codi, executar l’eina que construeix instal·lacions, etc., et tornaràs boig i faràs errades estúpides.

Per aquesta raó, la darrera empresa en què vaig treballar va canviar de WISE a InstallShield: vam exigir que el procés d’instal·lació fos capaç d’executar-se, des d’un script, automàticament, cada nit, utilitzant el programador de tasques de NT, i WISE no podia executar-se des del programador cada nit, així que vam renunciar-hi. (Els de WISE m’informen amablement que la seva última versió sí que suporta les recompilacions nocturnes).

3. Fas recompilacions diàries?
Quan utilitzes control de versions, a vegades algun programador fa accidentalment check in d’alguna cosa que trenca la compilació. Per exemple, han afegit un nou arxiu de codi i tot es compila perfectament a la seva màquina, però han oblidat afegir el nou arxiu al contenidor central del codi. Així que apaguen la seva màquina i se’n van a casa, despreocupats i feliços. Però ningú més no pot treballar, així que també se n’han d’anar a casa, gens feliços.

Trencar la compilació és tan dolent (i tan comú) que resulta útil fer recompilacions diàries, per assegurar-se que cap trencament passa desapercebut. En equips grans, una bona manera d’assegurar-se que els trencaments s’arreglen al moment és fer la recompilació diària cada migdia; a l’hora de dinar, posem per cas. Tothom fa tants check in com pot abans de dinar. Quan tornen, ja s’ha recompilat. Si ha funcionat, perfecte! Tothom agafa l’última versió del codi i continua treballant. Si la compilació ha fallat, l’arregles, però mentrestant tothom pot continuar treballant amb la versió anterior. En l’equip d’Excel teníem una norma segons la qual qualsevol que trenqués la compilació, com a "càstig", era responsable de tenir cura de les compilacions fins que algú altre la trenqués. Aquest era un bon incentiu per no trencar la compilació, i una bona manera d’encarregar alternativament a tothom el procés de recompilació per tal que aprenguessin com funcionava. Llegeix més sobre compilacions diàries en el meu article Les recompilacions diàries són les teves aliades.

4. Tens una base de dades d’errors?
M’és igual el que diguis. Fins i tot en un equip d’una sola persona, si estàs desenvolupant sense organitzar tots els errors coneguts del codi en una base de dades, publicaràs codi de baixa qualitat. Molts programadors pensen que poden tenir sempre al cap la llista d’errors. Bajanades. Jo no puc recordar més de dos o tres errors al mateix temps, i al matí següent, o amb les presses de la publicació de versió, els oblido. És totalment necessari que facis un seguiment formal dels errors.

Les bases de dades d’errors poden ser complicades o simples. La mínima base de dades d’errors útil ha d’incloure les següents dades per a cada error:

• passos concrets per reproduir l’error
• comportament esperat
• comportament (erroni) observat
• a qui està assignat
• si ha estat arreglat o no

Si els programes per fer seguiment d’errors et semblen massa complicats i això és el que t’impedeix fer el seguiment dels teus errors, munta’t només una taula amb 5 columnes amb aquests camps crucials i comença a utilitzar-la.

Per a més sobre el seguiment d’errors, llegeix Seguiment d’errors sense patiments.

5. Arregles els errors abans d’escriure codi nou?
La primera versió de Microsoft Word per a Windows va ser considerada un projecte de "marxa fúnebre". Va durar una eternitat. Només feia que endarrerir-se. Tot l’equip treballava quantitats absurdes d’hores, el projecte s’endarreria una vegada, i una altra, i una altra, i l’estrès era increïble. Quan finalment es va acabar amb la bèstia, Microsoft va enviar tot l'equip de vacances a Cancun, i es van asseure a fer una seriosa autocrítica.

El que van trobar és que els responsables de projecte havien insistit tant en mantenir la "planificació" que els programadors simplement desenvolupaven a tot gas, escrivint codi extremadament dolent, perquè la fase de reparació d’errors no formava part de la planificació formal. No hi havia cap intent de mantenir baix el recompte d’errors. Més aviat al contrari. La cosa anava així: un programador que havia d’escriure el codi que calculava l’alçada d’una línia de text escrivia només "return 12;" i esperava a que li arribés el report d’error de com aquesta funció no sempre era correcta. La planificació no era més que una llista de funcionalitat que estava esperant ser convertida en errors. En l’anàlisi post-mortem, això va ser anomenat la "metodologia d’infinits defectes".

Per corregir el problema, Microsoft va adoptar universalment quelcom anomenat la "metodologia de zero defectes". Molts programadors de l’empresa se’n reien, perquè sonava com si la direcció pensés que podien reduir el número d’errors per decret. De fet, "zero defectes" volia dir que en qualsevol moment, la prioritat més alta és eliminar els errors abans de fer codi nou. La raó és la següent.

En general, com més esperes abans d’arreglar un error, més costós (en temps i diners) és arreglar-lo.

Per exemple, quan fas un error tipogràfic o sintàctic que caça el compilador, arreglar-lo és bàsicament trivial.

Quan tens un error al codi que veus el primer cop que intentes executar-lo, seràs capaç d’arreglar-lo en un no res, donat que tens el codi encara fresc al cap.

Si trobes un error en codi que vas escriure fa uns dies, et costarà una mica localitzar-lo, però quan rellegeixis el codi que vas escriure, et vindrà tot al cap i seràs capaç d’arreglar l’error en un temps raonable.

Però si trobes un error en codi que vas escriure fa uns mesos, probablement hauràs oblidat moltes coses sobre aquell codi, i serà molt més difícil d’arreglar. En aquest cas potser estaràs arreglant el codi d’algú altre, qui potser està de vacances a Aruba, cas en el qual arreglar l’error és com una ciència: has de ser lent, metòdic, i meticulós, i no pots estar segur de quan et costarà descobrir la solució.

I si trobes un error en codi que ja ha estat publicat, incorreràs en uns costos increïbles per arreglar-lo.

Aquesta és una raó per corregir els errors al moment: costa menys temps. Hi ha una altra raó, relacionada amb el fet que és més fàcil predir quant de temps costarà escriure codi nou que arreglar un error existent. Per exemple, si et demano predir quant costaria escriure el codi per ordenar una llista, em podries donar una estimació bastant bona. Però si et demano predir quant costaria arreglar aquell error que fa que el teu codi no funcioni si Internet Explorer 5.5 està instal·lat, no pots ni tan sols endevinar-ho, perquè no saps (per definició) què causa l’error. Podria costar 3 dies esbrinar-ho, o 2 minuts.

El que això vol dir és que si tens una planificació amb molts errors pendents de resoldre, la planificació no és creïble. Però si has corregit tots els errors coneguts, i tot el que queda per fer és codi nou, aleshores la teva planificació serà sorprenentment més acurada.

Un altre gran què de mantenir el compte d’errors coneguts a zero és que pots respondre molt més ràpid a la competència. Alguns programadors veuen això com mantenir el producte preparat per lliurar en tot moment. Aleshores si el teu competidor introdueix una nova funcionalitat exitosa que t’està robant els clients, pots implementat tot just aquella funcionalitat i publicar al moment, sense haver d’arreglar un gran número d’errors acumulats.

6. Tens una planificació actualitzada?
La qual cosa ens porta a les planificacions. Si el teu codi té alguna importància per al negoci, hi ha moltes raons per les quals és important per als comercials saber quan el codi estarà acabat. Els programadors són notòriament àcids quan es tracta de fer planificacions. "Estarà quan estigui!", criden als comercials.

Malauradament, amb això no n’hi ha prou. Hi ha massa decisions de planificació que els comercials necessiten fer amb prou avançament respecte la publicació del codi: demos, shows comercials, publicitat, etc. I l’única manera de fer-ho és tenir una planificació, i portar-la al dia.

L’altra cosa important de tenir una planificació és que et força a decidir quines funcionalitats faràs, la qual cosa t’obliga a seleccionar les característiques menys importants i eliminar-les en lloc de caure en la "featuritis", o creixement descontrolat de l’abast.

Portar planificacions no té per què ser difícil. Llegeix el meu article Planificacions de programari sense patiments, que descriu una manera senzilla de fer grans planificacions.

7. Tens especificacions?
Escriure especificacions és com utilitzar seda dental: tothom està d’acord en que és bo, però ningú no ho fa.

No estic segur de per què és així, però probablement és perquè la majoria de programadors odien fer documents. En conseqüència, quan equips formats només per programadors ataquen un problema, prefereixen expressar la seva solució en codi, més que no en documents. Prefereixen mil vegades submergir-se en l’escriptura de codi que produir unes especificacions abans.

En la fase de disseny, quan descobreixes problemes, els pots solucionar fàcilment editant unes poques línes de text. Una vegada escrit el codi, el cost d’arreglar problemes és molt més alt, tant des del punt de vista emocional (la gent odia llençar codi) com en termes de temps, així que hi ha resistència a arreglar realment els problemes. El programari que no s’ha construït a partir d’una especificació sovint acaba estant mal dissenyat i la planificació se’n va de mare. Aquest sembla haver estat el problema a Netscape, on les primeres quatre versions van convertir-se en un desori tan gran que la direcció va decidir estúpidament llençar el codi i començar de nou. I després van repetir aquest error també amb Mozilla, creant un monstre que va quedar fora de control i es van tardar uns quants anys a aconseguir que arribés a la fase alfa.

La meva teoria personal és que aquest problema pot resoldre’s ensenyant als programadors a perdre-li la por a escriure, mitjançant un curs intensiu d’escriptura. Una altra solució és contractar programadors brillants que produeixin l’especificació escrita. En qualsevol cas, hauries de fer complir la senzilla norma "cap codi sense especificacions".

Aprèn tot sobre escriure especificacions amb la meva sèrie de 4 articles.

8. Els programadors tenen condicions de treball tranquil·les?
Hi ha uns guanys de productivitat extensament documentats, que s’obtenen quan es dona als treballadors del coneixement espai, calma i privacitat. El clàssic llibre de direcció d’informàtica Peopleware explica molt bé aquests beneficis en productivitat.

Aquest és el problema. Tots sabem que els treballadors del coneixement treballen millor quan aconsegueixen entrar en el "flux", també conegut com estar "en la zona", on estan totalment concentrats en el seu treball i completament desconnectats del seu entorn. Perden la noció del temps i produeixen grans coses mitjançant la concentració absoluta. Així és com aconsegueixen fer tot el seu treball productiu. Els escriptors, programadors, científics, fins i tot els jugadors de bàsquet et parlaran d’estar en la zona. El problema és que entrar a "la zona" no és fàcil. Quan intentes mesurar-ho, resulta que fa falta una mitjana de 15 minuts per començar a treballar a la màxima productivitat. A vegades, si estàs cansat o ja has fet molt de treball creatiu en el dia, simplement no pots entrar a la zona i et passes la resta del dia laborable perdent el temps, llegint coses a la xarxa, jugant al Tetris.

L’altre problema és que és molt fàcil que se’t tregui de la zona. El soroll, les trucades, sortir a dinar, haver de conduir 5 minuts fins a Starbucks per fer un cafè, i les interrupcions dels companys de feina – especialment les interrupcions dels companys de feina – són coses que et treuen de la zona. Si un company et fa una pregunta, causant una interrupció d’1 minut, però això et treu de la zona fins al punt que et fa falta mitja hora per tornar a ser productiu, la teva productivitat global en sortirà malparada. Si estàs en un ambient sorollós i frenètic del tipus que a les dotcoms els encanta crear, amb els tipus de marketing cridant al telèfon al costat de programadors, la teva productivitat s’enfonsarà, ja que els treballadors del coneixement seran interromputs constantment i no aconseguiran mai entrar a la zona.

Amb els programadors, és especialment dur. La productivitat depèn de ser capaç de mantenir molts petits detalls al mateix temps en la memòria a curt termini. Qualsevol tipus d’interrupció pot causar que aquests detalls s’ensorrin. Quan retornes al treball, no pots recordar cap dels detalls (com els noms de les variables locals que estaves utilitzant, o bé on estaves en la implementació d’aquell algorisme de cerca) i has de continuar consultant les mateixes coses, la qual cosa t’alenteix molt fins que aconsegueixes recuperar el ritme.

L’àlgebra és senzilla. Diguem (com l’evidència suggereix) que si interrompem un programador, ni que sigui per un minut, estem realment llençant 15 minuts de productivitat. Per a aquest exemple, agafem dos programadors, Jeff i Mutt, en cubicles oberts l’un al costat de l’altre en una típica granja a l’estil Dilbert. Mutt no pot recordar el nom de la versió Unicode de la funció strcpy. Podria buscar-ho, que li costa 30 segons, o preguntar-ho a Jeff, que li costa 15 segons. Com que està seient just al costat de Jeff, ho pregunta a Jeff. Jeff es distreu i perd 15 minuts de productivitat (per estalviar-li a Mutt 15 segons).

Ara moguem-los a oficines separades, amb parets i portes. Ara quan Mutt no pot recordar el nom d’aquella funció, podria consultar-ho, que li segueix costant 30 segons, o preguntar a Jeff, que ara li costa 45 segons i implica aixecar-se (una tasca no gens fàcil, tenint en compte l’estat físic normal dels programadors!). Així que ho consulta. Ara Mutt perd 30 segons de productivitat, però estalviem 15 minuts per a Jeff. Ahhh!

9. Utilitzes les millors eines que es poden comprar?
Escriure codi en llenguatge compilat és una de les últimes coses que encara no són instantànies en un ordinador personal típic. Si la teva compilació requereix més d’uns pocs segons, obtenir l’ordinador més gran i més nou t’estalviarà temps. Si la compilació tarda ni que siguin 15 segons, els programadors s’avorriran mentre el compilador treballa i es posaran a llegir The Onion, que els absorbirà, matant hores de productivitat.

Debugar codi GUI amb un sistema d’un únic monitor és una tasca àrdua, si no impossible. Si estàs escrivint codi GUI, dos monitors faran les coses molt més fàcils.

La majoria de programadors en algun moment han de manipular mapes de bits per a icones o barres d’eines, i la majoria de programadors no tenen un bon editor de mapes de bits a la seva disposició. Intentar utilitzar Microsoft Paint per manipular mapes de bits és una broma, però és el que la majoria de programadors han de fer.

A la meva antiga feina, l’administrador del sistema m’enviava contínuament spam automàtic queixant-se de que estava utilitzant més de ... no t’ho perdis ... 220 megabytes d’espai de disc dur en el servidor. Vaig fer-li l’observació que donat el preu dels discos durs en aquell moment, el cost d’aquest espai era significativament més petit que el cost del paper higiènic que utilitzava. Passar-me fins i tot 10 minuts netejant el meu directori hauria estat una increïble pèrdua de productivitat.

Els millors equips de desenvolupament no torturen els seus programadors. Fins i tot les frustracions menors causades per l’ús d’eines no prou capaces s’acaben acumulant, tornant els programadors malhumorats i descontents. I un programador malhumorat és un programador improductiu.

Com a afegitó... als programadors se’ls compra fàcilment donant-los els productes més moderns i atractius. Aquesta és una manera molt més barata de fer-los treballar per a tu que no pas pagar-los salaris realment competitius!

10. Tens testejadors?
Si el teu equip no té testejadors amb dedicació plena, almenys un per cada dos o tres programadors, o bé estàs comercialitzant productes defectuosos, o bé estàs llençant els diners per tenir programadors de 100$ l’hora fent una feina que pot ser feta per testejadors de 30$ l’hora. Estalviar testejadors és un fals estalvi tan flagrant que simplement em sorprèn que més gent no ho reconegui.

Llegeix Cinc grans raons (equivocades) per les quals no tens testejadors, un article que vaig escriure sobre el tema.

11. Els nous candidats escriuen codi durant l’entrevista?
Contractaries un mag sense demanar-li que t’ensenyi alguns trucs de màgia? Per descomptat que no. Contractaries un proveïdor per al dinar del teu casament sense tastar el seu menjar? Ho dubto. (Tret que sigui la Tieta Margarida, i t’odiaria per sempre si no li deixessis fer el seu "famós" pastís de fetge picat).

Però cada dia es contracta programadors en base a un currículum impressionant o perquè l’entrevistador s’ho va passar bé xerrant amb ells. O se’ls pregunten qüestions trivials ("quina diferència hi ha entre CreateDialog() i DialogBox()?") que podrien contestar-se mirant la documentació. No t’importa si han memoritzat milers de dades concretes sobre programació, t’importa si són capaços de produir codi. O, encara pitjor, se’ls fan preguntes de "TXAS!", d’aquelles que semblen fàcils quan saps la resposta, però si no la saps són impossibles.

Si us plau, prou de fer això. Fes el que vulguis durant l’entrevista, però fes que el candidat escrigui codi. (Per a més consells, llegeix la meva Guia de guerrilla per fer entrevistes.)

12. Fas tests d’utilitzabilitat al passadís?
Fer un test d’utilitzabilitat al passadís és agafar la primera persona que passa pel passadís i forçar-la a intentar utilitzar el codi que acabes d’escriure. Si fas això amb cinc persones, aprendràs el 95% del que hi ha per aprendre sobre problemes de facilitat d’ús en el teu codi.

El disseny de bones interfases d’usuari (IU) no és tan difícil com pensaries, i és crucial si vols que als clients els encanti i comprin el teu producte. Pots llegir el meu llibre en xarxa sobre disseny d’IU, una breu iniciació per a programadors.

Però el més important sobre les interfases d’usuari és que si ensenyes el teu programa a un grapat de gent (de fet, amb cinc o sis n’hi ha prou), descobriràs ràpidament els problemes més grans que té la gent. Llegeix l’article de Jakob Nielsen que explica per què. Fins i tot si els teus coneixements de disseny d’IU són escassos, des del moment en què et forces a fer tests de facilitat d’ús al passadís, que no et costen res, la teva IU serà molt, molt millor.

Quatre maneres d’utilitzar el Test de Joel

1. Puntua la teva pròpia organització d’informàtica, i digue’m quina qualificació té, perquè pugui xafardejar.
2. Si ets el cap d’un equip de programadors, utilitza això com una llista de punts per assegurar-te que el teu equip està treballant tan bé com és possible. Quan comencis a puntuar a 12, pots deixar sols els teus programadors i centrar-te completament a evitar que la gent de comercial els molesti.
3. Si estàs intentant decidir si agafes un treball de programador, demana a qui t’està entrevistant com puntuen en aquest test. Si és massa baix, assegura’t que tindràs l’autoritat per arreglar això. Altrament estaràs frustrat i seràs improductiu.
4. Si ets un inversor fent gestions per jutjar el valor d’un equip de programadors, o si la teva empresa d’informàtica s’està plantejant fusionar-se amb una altra, aquest test et pot donar una indicació ràpida.