Peter Pan informàtic?

Fa molts anys, quan vaig deixar una feina, algú em va donar un consell: "Com més lluny de la tecnologia, millor".
Ho deia amb la millor de les intencions. Realment, en el sector informàtic, els que cobren més diners són els que estan més lluny de la tecnologia, fent gestió.

Això té dues implicacions. La primera és que la majoria dels estudiants d'Informàtica el que volen fer un cop deixen la carrera és "estar el més lluny de la tecnologia". Se saben la lliçó. D'aquesta manera és difícil trobar perfils tècnics de qualitat, encara que vulguis pagar bé, per què s'han anat desfent pel camí.

La segona implicació que jo veig és que hi ha una sensació de que estar a prop de la tecnologia és dolent. Aquells que es mantenen propers, no han volgut créixer. Són uns Peter Pan. Així que un cop arribes a un lloc de gestió, rebutges tot el que tingui a veure amb la tecnologia. Per si de cas.

És clar que és impossible fer una bona gestió si a més a més estàs amb el dia a dia. No crec que sigui bo tampoc que un Director General estigui administrant una base de dades, gestionant un Firewall o codificant un algorisme. Això també crec que és un error.

A mi em sembla que estar a prop de la tecnologia quan evoluciones dintre de la carrera professional d'informàtic és bo. Potser no podràs estar per tot, ni podràs fer la feina que fan els professionals que gestiones, però serà més fàcil de gestionar.

Si vam triar una carrera tècnica, d'alguna manera ens agradava, no? Jo crec que del que es tracta és de mantenir el que una amiga anomenava "trempera tecnològica". Crec jo.

Els comentaris al codi menteixen

Quan vaig començar en el món de la programació creia que un bon codi era aquell que estava ben documentat, amb comentaris. Quan vaig descobrir el Javadoc vaig pensar que era un gran invent i, fins i tot, vaig fer servir en un projecte una eina de validació que m'informava si havia algun mètode sense comentari. Amb el temps em vaig anar adonant que menys del 5% dels mètodes tenien comentaris que aportessin alguna cosa: la majoria eren parafrasejats del nom del mètode o texts absurds per evitar que es disparessin les alertes de que faltava el comentari.

Al llibre de Clean Code hi ha una anàlisi molt interessant dels comentaris al codi. En Robert C. Martin fa una afirmació categòrica: Els comentaris menteixen. Al més pur estil House.
Els programadors no tenen temps per mantenir els comentaris. Si els comentaris no estan bé el codi pot funcionar igual de bé, i no alertarà el compilador d'aquest fet. I com no pot haver control més enllà de la voluntat, amb el temps els comentaris s'allunyen tant de la intenció original que arriben a ser perjudicials.

L'oncle Bob proposa desenvolupar el codi de manera que sigui molt expressiu. Fer servir noms de mètodes i de variables molt clars, i variables intermitges si s'escau. El codi ha de ser prou clar. Si cal un comentari, mira com pots canviar el codi per que no sigui necessari.

Tots els comentaris són dolents per definició, doncs? No. Segons el llibre Clean Code, quis serien els comentaris acceptables?
De vegades és necessari explicar per què fas servir una estratègia concreta, o per aclarir. Els comentaris de coses per fer (els TODO) també són molt útils. I també són útils els JavaDoc de les API públiques. Però no facis més comentaris dels que puguis mantenir.

Com a comentaris dolents posa un bon grapat d'exemples. Llegint-los te n'adones que de vegades has estat autor d'algun d'aquests: Comentaris redundants, comentaris absurds als getters i setters, comentaris per farcir, el que estàs rumiant (per que no ho tens clar), l'històric dels canvis (ja tens l'eina de control de versions), indicador de final de clau (o el END en altres llenguatges), marcador d'on comencen els mètodes d'un determinat tipus, codi comentat per que no es fa servir, ...

Trobo molt útil, com a reflexió, pensar dues vegades abans de posar un comentari al codi.

Per cert, em van passar un enllaç sobre comentaris divertits al codi. N'hi ha per partir-se.

Java, orientació a objectes i la llosa del PL/SQL

Al capítol 6 del llibre Clean Code l'autor fa una reflexió sobre la diferència entre pensar en dades i pensar en objectes. Quan penses en dades t'interessa exposar les dades i et dóna el mateix el comportament. Quan penses en objectes, t'interessa exposar el comportament i amagar les dades tot el que puguis. Són oposats.

El Java és un llenguatge que et permet desenvolupar perfectament sense aprofitar de cap manera els beneficis de la orientació a objectes. Pots fer un programa perfectament procedural. De fet, molt del codi que vaig trobant és eminentment procedural. Poc a poc vaig trobant alguna aplicació de patrons, o com a mínim de disseny Orientat a Objectes, però no tant com hauria.

I me n'adono d'un altre perill. Als entorns on la base de dades Oracle és present és molt fàcil que una part del codi s'hagi desenvolupat en PL/SQL. És fàcil que hi hagin triggers i també que es facin servir procediments i funcions. Fins i tot que una part de la lògica d'accés a dades estigui encapsulada en aquest llenguatge.

Ja hem vist que pensar en estructures de dades i pensar en objectes comporten models mentals oposats. I és molt probable que els desenvolupadors que s'encarreguen del PL/SQL siguin els mateixos que s'encarreguen del Java, i quan toquen el Java és molt difícil que deixin la inèrcia de pensar en procedural.

En aquest sentit penso que el PL/SQL és una llosa pel bon desenvolupament Orientat a Objectes. Com a mínim cal tenir en compte aquesta dificultat, i el programador de PL/SQL ha de tenir clar que ha de fer un esforç especial amb la Orientació a Objectes.

Quan la qualitat és un luxe

Ahir vaig quedar a dinar amb els meus antics companys de feina i, evidentment, em van preguntar com em va ara. El que més els va sobtar va ser que ara tenim un equip d'unes set persones de Control de Qualitat (que li diem QA, de Quality Assurance). Aquestes persones són coneixedors de l'aplicació i tenen molt formalitzat què ha de fer l'aplicació. A cada versió que es fa passen una bateria de proves i miren que els resultats són els esperats.

Clar que els va sobtar aquest model. Tanta gent per fer proves? A l'antiga empresa el costum era fer el que aquests de QA anomenen smoke test, fer quatre clics per veure que no peta escandalosament. Les proves de veritat les feia el client en producció quan rebia la nova versió. Tot s'ha de dir que ara, a l'antiga empresa, fan una miqueta més de proves.

I per què aquest model tan allunyat a la qualitat funciona? Segueixen tenint molts clients, no perden els antics i de tant en tant guanyen de nous. Les aplicacions surten al carrer plenes de defectes (de bugs) i no hi ha problema.Vist des d'aquest punt de vista, des del punt de vista empresarial dedicar recursos a la qualitat és llençar els diners. La qualitat és un luxe.

Aquesta afirmació em regira els budells. No pot ser veritat. Què és el que no funciona? O, què és diferent entre les dues empreses? L'altre dia el meu amic em va recordar que en el desenvolupament de projectes hi ha tres variables en joc de les quals només pots triar dues: l'abast (les funcionalitats a cobrir), el cost (o la data de lliurament) i la qualitat. Si has d'implementar totes les funcionalitats o corregir tots els bugs i la data de lliurament no es pot moure, només pots sacrificar la qualitat. Si a més a més els processos no acompanyen, i l'organització no es capaç de modificar l'abast, destinar més recursos o modificar la data, només queden les hores extres i les nyapes (a qui no li sona?)

Si això es converteix en dinàmica, cada cop és més difícil fer les coses bé. Això és evident. I com pot ser que lliurant productes tan defectuosos segueixis en el mercat?

Rumiant, rumiant, he arribat a un parell de motius (que es converteixen en un de sol).

El primer és l'absència de competència real. Si estàs en un sector on no hi ha una alternativa real al teu producte, i els teus clients han de cobrir unes necessitats, hauran de passar pel tub. Si és un sector emergent, cal anar per davant de la competència, i això obliga a tenir dates de lliurament molt ajustades. Si aconsegueixes calmar al client després de tots els bugs que li afegeixes després de cada versió, aconseguiràs transformar la ràbia inicial client, en una sensació de que li estàs fent una feina a mida.

Però el que crec que realment marca la diferència és el cost del canvi (switching cost). I això inclou també el motiu anterior: si no pots canviar a un producte de la competència, el cost és inabastable. Però el que està clar és que hi ha productes informàtics que són més difícils de substituir que altres. I molts fabricants ho persegueixen, buscant l'efecte "client captiu".

Quins productes són difícils de substituir? Jo crec que els ERP, els motors de base de dades, els servidors de correu i bàsicament tots els productes que tinguin una infraestructura complexa d'instal·lació, emmagatzemin dades i les dades siguin difícils de transformar. Al final tot és canviable, però el que importa és com de difícil sigui el canvi.

I quins són els productes fàcils de substituir? Jo veig els antivirus, les eines ofimàtiques i tot el que sigui "software as a service" i que no emmagatzemi dades.

Si el teu producte és un cercador de feina, un portal de venda on-line, o una base de dades d'algun sector molt específic, més val que t'apliquis amb la qualitat. Com deia el Steve Krugg al llibre Don't Make me Think "A Internet la competència és a un clic...".

Són quatre empreses

Amb la competència que hi ha ara sembla que l'única manera de sobreviure per a les grans companyies es fer-se més i més grans. Com a mínim és el que anem veient al sector informàtic.

Anem veient anuncis que les grans (Microsoft, Google, Oracle, HP, IBM, etc) van comprant companyies més petites (i no tan petites). L'altre dia HP anunciava que es quedava amb Palm. Però molt sovint se'ns queda la cara de tonto : "què la companyia X ara és de Y?".

I la que darrerament es portava la palma era Oracle. Es va menjar PeopleSoft (just quan s'havien menjat JDEdwards), Siebel, BEA (que era líder en servidors d'aplicacions), innobase (els que estaven darrera del component transaccional de MySQL) i la bomba va ser quan van comprar Sun (que just acabaven de comprar MySQL).

Sun són els pares de moltes tecnologies que han estat fonamentals pel desenvolupament informàtic. Amb l'adquisió de Sun Oracle posava un peu en el mon del hardware i dels sistemes operatius, però també es ficava a la butxaca el Java. I això sí que fa molta por.

I és que els moviments d'Oracle també són importants en la banda del OpenSource. Estan ficats de ple amb Eclipse, tot i que ara tenen dos IDE Java: JDeveloper i NetBeans. I també van comprar Berkeley DB, la base de dades que està darrera del Subversion.

I cal anar amb compte quan vas pensant en OpenSource, per què has de veure quines companyies hi ha darrera. JBoss i Hibernate, per exemple, són de RedHat. I el Spring Framework és de VMWare.

Tanta concentració fa por. De vegades penso en aquelles fantasies cyberpunk en les que no existien països ni fronteres, sinó que només hi havia grans corporacions. Més d'un portaria la senyera de Google, d'Oracle o de Microsoft. De tota manera crec que anirem veient més concentració encara. Qui serà comprat demà?