Esiste una forza invisibile che trasforma un elegante script Python in un mostro di spaghetti code impossibile da manutenere, e no, non è solo la mancanza di caffè.
Sfoggiando per caso una raccolta di principi che chiamano «Laws of Software Engineering», mi sono ritrovato davanti a uno specchio deformante della mia intera esistenza da smanettone. Non è un manuale di istruzioni, ma una lista di verità scomode che governano tutto ciò che scrivi, progetti e—soprattutto—distruggi.
Partiamo dalle basi, quelle che ti fanno capire perché il tuo progetto CNC o la tua nuova IA custom sono diventati un incubo. C’è la Legge di Conway, che dice chiaramente che il software riflette la struttura dell’organizzazione che lo crea. In pratica, se il team di comunicazione è un disastro, il codice sarà un disastro. E poi c’è la Legge di Brooks: aggiungere gente a un progetto in ritardo lo rende solo più in ritardo. È la fisica del software: non puoi risolvere un problema di logica aggiungendo solo forza bruta (o solo altri developer che non sanno dove mettere le mani).
Ma la parte più divertente, quella che ti fa sentire meno in colpa quando il tuo sistema crasha, è la Legge di Hyrum. Dice che se hai abbastanza utenti, tutti i comportamenti osservabili della tua API diventeranno dipendenze critiche. In breve: non puoi cambiare nulla senza rompere tutto il mondo. È la fine della libertà, un vero incubo per chi ama il refactoring selvaggio.
Per noi che amiamo smontare le cose, queste leggi sono fondamentali. Quando stiamo modellando un pezzo in Blender o programmando un modulo in Godot, tendiamo a cadere nella trappola dell’ottimizzazione prematura o del YAGNI (You Aren’t Gonna Need It). Ma la verità è che la complessità non scompare, si sposta soltanto, come recita la Legge di Tesler. Se non la gestisci nel design, la troverai sotto forma di bug bastardi quando proverai a compilare.
Il mio consiglio? Leggete queste leggi, ma non usatele come scusa per la pigrizia. Usatele per capire dove si annida il debito tecnico e come evitare l’effetto secondo sistema, ovvero quel desiderio compulsivo di creare versioni sovra-ingegnerizzate e pesantissime di qualcosa che funzionava benissimo quando era semplice.
Alla fine della fiera, resta la Legge di Sturgeon: il 90% di tutto è spazzatura. Il nostro compito è cercare di far sì che quel 10% di genialità sia almeno leggibile e, soprattutto, che non esploda alla prima riga di codice che tocchiamo.
Source: Laws of Software Engineering