Un buon programmatore è elegante e conciso

All’epoca le capacità della maggior parte dei computer erano molto limitate. La memoria dell’Ibm 704 poteva contenere solo quattromila parole. Un buon programmatore era elegante e conciso, non usava mai una parola di troppo. Erano poeti dei bit. “Era come lavorare con una serie di rompicapi logici”, racconta Wilkes. “Sono ancora molto pignola e precisa. Fino all’eccesso. Noto ogni minimo dettaglio”.

Al di là dell’importante apporto che questo articolo di Internazionale aggiunge alla ricostruzione del ruolo femminile nella storia dell’informatica, uno dei passaggi della Wilkes che mi è capitato di evidenziare è questo legato alla puntigliosità con cui, per la scarsità delle risorse e il prestigio del lavoro, veniva scritto il codice.

Oggi le risorse abbondano, scrivere codice è infinitamente più semplice – in rapporto alle complessità delle tecnologie per le quali si sta sviluppando – e di guide, framework e stralci di codice che fanno già le cose che bisognerebbe programmare per farle ne è pieno il web. Scrivere codice gustoso, asciutto e raffinato nelle soluzioni non può essere solo il vezzo di qualche informatico fobico, è una caratteristica che bisognerebbe pesare correttamente nella selezione e valutazione di progetti e sviluppatori. Oggi non succede a sufficienza.

Perché la programmazione non è cambiata?

Quando un programmatore ha la testa infilata nel proprio editor, se la complessità della porzione di codice sulla quale sta lavorando va un po’ oltre Hello World, può succedere che a causa della concentrazione, dell’isolamento e dell’applicazione nel far funzionare il proprio codice, può venire totalmente astratto dal progetto, perdendo paradossalmente il focus sull’obiettivo finale.

“The problem is that software engineers don’t understand the problem they’re trying to solve, and don’t care to,” says Leveson, the MIT software-safety expert. The reason is that they’re too wrapped up in getting their code to work. “Software engineers like to provide all kinds of tools and stuff for coding errors,” she says, referring to IDEs. “The serious problems that have happened with software have to do with requirements, not coding errors.” When you’re writing code that controls a car’s throttle, for instance, what’s important is the rules about when and how and by how much to open it. But these systems have become so complicated that hardly anyone can keep them straight in their head. “There’s 100 million lines of code in cars now,” Leveson¹ says. “You just cannot anticipate all these things.”

James Somers ha pubblicato su The Atlantic un long-form sull’apocalisse del software. L’articolo attraversa analisi illuminanti sullo stato del lavoro di programmazione: si scrivono milioni di righe di codice che, causa la difficoltà nello scriverle, spesso astraggono lo sviluppatore dal problema per il quale quel codice si sta scrivendo.

I nostri team non hanno mai costruito un software per pilotare un Boeing 747 ma possiamo dire di aver comunque sviluppato software per grosse aziende e, dalla mia esperienza, in ogni progetto ho notato questo problema. Il focus sulla funzionalità del codice – sulle metodologie, sugli approcci, sulle strategie, sulla correzione degli errori e sulle logiche – ha causato qualche volta l’allontanamento dall’obiettivo finale, dal problema per il quale il software era in sviluppo.

La tecnologia si è evoluta, il modo in cui essa viene sviluppata è rimasto pressoché identico.

Il problema è quindi il codice?

The problem is that programmers are having a hard time keeping up with their own creations. Since the 1980s, the way programmers work and the tools they use have changed remarkably little. […] Computers had doubled in power every 18 months for the last 40 years. Why hadn’t programming changed? […] the idea that people were doing important work, like designing adaptive cruise-control systems or trying to understand cancer, by staring at a text editor, was appalling. And it was the proper job of programmers to ensure that someday they wouldn’t have to.