Sistemes i Arquitectura
L'avorrit és una característica
Per què triar deliberadament tecnologia avorrida és sovint la decisió arquitectònica més responsable que pots prendre.
5 min
La majoria del programari no falla per manca d’innovació. Falla perquè acumula complexitat més ràpid del que acumula comprensió.
La seducció de la novetat
Hi ha un patró recurrent als equips d’enginyeria. Comença un nou projecte, les restriccions són poques i l’equip té llibertat real. Gairebé de seguida, algú proposa fer servir el framework més recent, el motor de base de dades més nou, el llenguatge del qual la comunitat porta sis mesos entusiasmada.
El raonament sempre sona sensat: millor rendiment, millor experiència de desenvolupament, abstraccions més modernes. El que rarament es diu en veu alta és que aquestes eleccions tenen un cost ocult: un que no pagaran els qui el prenen, sinó qui mantingui el sistema dos o tres anys després.
La factura arriba tard
La novetat és cara, però la factura arriba més tard.
Quan un sistema es construeix sobre tecnologia desconeguda o immadura, el cost es difereix. A curt termini, tot sembla bé. L’equip està motivat. La velocitat és alta. El sistema fa el que es va dissenyar per fer.
La factura arriba quan alguna cosa falla a les 3 de la matinada i el runbook no cobreix aquesta versió particular de la dependència. Arriba quan els enginyers originals marxen i el nou equip passa setmanes intentant entendre una decisió que en el seu moment semblava òbvia. Arriba quan el framework publica un canvi que trenca la compatibilitat i una migració que hauria de portar un dia porta un trimestre.
Aquests costos són reals, però són invisibles en el document de planificació. No apareixen en la velocitat de l’sprint. S’acumulen en silenci, fins que es converteixen en un sostre sobre tot el que l’equip pot fer.
Què significa realment “avorrit”
Triar tecnologia avorrida no és el mateix que ser conservador, avers al risc o poc ambiciós. És entendre quin tipus de risc s’està acceptant.
Els sistemes avorrits fallen de maneres previsibles. Quan una instància de Postgres es queda sense connexions, l’error està ben documentat, la solució és ben coneguda i la comunitat ho ha vist mil vegades. Quan la teva memòria cau distribuïda a mida falla sota un patró d’escriptura inusual, estàs depurant a les fosques.
La tecnologia avorrida té millor documentació. Té respostes a Stack Overflow de fa vuit anys que continuen sent vàlides. Té llibres escrits sobre els seus modes de fallada. Té enginyers disponibles per contractar que no necessiten sis mesos de formació abans de ser productius.
El més important: la tecnologia avorrida permet que un equip es concentri en el problema real que intenta resoldre, en lloc de la infraestructura que va triar per resoldre’l. Aquest és l’objectiu. L’avantatge competitiu ha de venir de la lògica de domini, no de la novetat de la capa d’emmagatzematge.
Gastar els tokens d’innovació amb seny
Dan McKinley va introduir el concepte de “tokens d’innovació”: la idea que qualsevol equip té un pressupost limitat per a eleccions no convencionals. Gastar un token en una nova base de dades significa tenir-ne un menys per al model de dades innovador que el producte realment necessita. Gastar un token en un llenguatge emergent significa tenir-ne un menys per a l’estratègia de memòria cau inusual que l’escala demana.
Usats amb intel·ligència, els tokens d’innovació produeixen avantatge real. Usats sense cura, produeixen diagrames d’arquitectura impressionants i equips lents.
La pregunta mai no és “és interessant aquesta tecnologia?” La pregunta és “és aquest el lloc correcte per gastar un token?”
Quan la novetat es guanya el seu lloc
Hi ha casos legítims per a la nova tecnologia. Quan una opció provada genuïnament no pot complir el requisit —no “podria no complir-lo algun dia” sinó que demostrablament no pot—, la novetat es guanya el seu lloc.
Quan l’equip té experiència prèvia profunda amb la nova tecnologia i el risc és entès en lloc d’assumit, el càlcul canvia. Quan l’organització té la maduresa operativa i la capacitat per absorbir una corba d’aprenentatge, la inversió pot justificar-se.
Però aquests casos són més rars del que els equips assumeixen. La majoria d’aplicacions no tenen requisits d’escala que justifiquin un sistema distribuït personalitzat. La majoria d’equips no tenen la profunditat operativa per gestionar infraestructura que encara no entenen.
A la pràctica
A la pràctica, això significa començar amb l’elecció avorrida i exigir un cas clar per desviar-se’n. Significa preguntar “què passa quan això falla?” abans de preguntar “quins són els benchmarks?”
Significa construir sistemes que el proper enginyer pugui entendre sense llegir una wiki interna que ningú ha actualitzat en divuit mesos. Significa escriure codi que l’equip pugui continuar raonant quan els autors originals ja no hi siguin.
La bona arquitectura no va d’impressionar. Va de ser fiable.
I la fiabilitat, la major part del temps, s’assembla molt a l’avorrit.