12 dilemmi etici che tormentano gli sviluppatori oggi

Il mondo della tecnologia è sempre stato a lungo sul potere e a corto di pensare alle ramificazioni di questo potere. Se può essere costruito, ci sarà sempre qualcuno che lo costruirà senza contemplare un modo più sicuro e più sano di farlo, per non parlare se la tecnologia dovrebbe essere costruita in primo luogo. Il software viene scritto. A chi importa dove e come viene utilizzato? Questo è un compito per qualcuno in qualche ufficio all'angolo.

Più preoccupante: mentre i corsi di etica sono diventati un punto fermo dei diplomi in ingegneria del mondo fisico, rimangono un'anomalia riluttante nella pedagogia dell'informatica. Tuttavia, poiché il software prende il sopravvento su una parte maggiore della nostra vita, le ramificazioni etiche delle decisioni prese dai programmatori diventano solo maggiori. Ora che il nostro codice è contenuto in frigoriferi, termostati, rilevatori di fumo e altro ancora, le mosse sbagliate, la mancanza di lungimiranza o un processo decisionale decisamente dubbio può perseguitare l'umanità ovunque vada.

[Cosa c'è dentro e cosa c'è nello sviluppo di app: 15 tendenze di programmazione calde e 15 che diventano fredde. | Mostra quanto sai veramente sullo sviluppo eseguendo il nostro test del QI di programmazione, round 3 e il nostro quiz sui linguaggi di programmazione "Hello, world". | Lavora in modo più intelligente, non di più: scarica la Guida alla sopravvivenza per sviluppatori da per tutti i suggerimenti e le tendenze che i programmatori devono conoscere. | Tieniti aggiornato sulle ultime notizie dagli sviluppatori con la newsletter di Developer World. ]

Quelli che seguono sono alcuni dei dilemmi etici che gli sviluppatori devono affrontare ogni giorno, che lo sappiano o no. Non ci sono risposte facili, in una certa misura perché la natura stessa del lavoro è così astratta. A peggiorare le cose, il business è diventato così inestricabilmente legato alla tecnologia informatica che è difficile bilanciare le esigenze e le motivazioni di tutte le parti coinvolte nel tentativo di impedire che la caratteristica del business case di oggi diventi l'incubo orwelliano di domani.

Il trucco è pensare oltre l'attuale zeitgeist e anticipare ogni utilizzo futuro di ciò che costruisci. Abbastanza semplice, eh? Considera questo meno come una guida per prendere le tue decisioni e più come un punto di partenza per il tipo di contemplazione etica che dovremmo svolgere come parte quotidiana del nostro lavoro.

Dilemma etico n. 1: file di registro: cosa salvare e come gestirli

I programmatori sono come i topi da soma. Tengono registrazioni di tutto, spesso perché è l'unico modo per eseguire il debug di un sistema. Ma i file di registro tengono traccia anche di tutto ciò che fanno gli utenti e, nelle mani sbagliate, possono esporre fatti che gli utenti vogliono mantenere segreti.

Molte aziende si basano sulla protezione attiva dei file di registro. Alcuni servizi di backup remoto promettono persino di mantenere copie aggiuntive in posizioni geografiche disparate. Non tutte le aziende aspirano a tale diligenza. Snapchat, ad esempio, ha costruito il suo marchio facendo un pessimo lavoro di backup dei dati, ma i suoi utenti sono attratti dalla libertà del sistema smemorato.

La mera esistenza di file di registro pone diverse domande etiche. Sono adeguatamente protetti? Chi ha accesso? Quando diciamo di distruggere i file, vengono veramente distrutti?

Il punto cruciale è accertare quali informazioni valga la pena conservare, dati i rischi di farlo, etici o meno. Qui il futuro complica l'equazione. Negli anni '60 il fumo era ampiamente accettato. Nessuno ci avrebbe pensato due volte a tenere traccia delle abitudini di fumo delle persone. Oggi, tuttavia, la conoscenza dell'attività del fumo di qualcuno può essere utilizzata per aumentare i tassi di assicurazione sanitaria o addirittura negare la copertura.

Affari futuri; future normative governative; un bisogno imprevisto e disperato di nuovi flussi di entrate: potrebbe essere impossibile prevedere quale file di registro apparentemente innocente diventerà problematico in futuro, ma è essenziale considerare l'etica di come gestite i registri lungo il percorso.

Dilemma etico n. 2: se - e come - trasformare gli utenti in prodotti

È un vecchio adagio dell'era delle startup: se non stai pagando per un servizio, non sei un cliente; tu sei il prodotto.

Su Internet, i servizi "gratuiti" abbondano. In effetti, la questione della provenienza dei soldi è spesso rimandata, essendo scoraggiante. Costruiamo semplicemente la meraviglia, teniamo d'occhio le metriche di adozione e immaginiamo che qualcun altro si occuperà del lavoro sporco di tenere accese le luci del server. Nel peggiore dei casi, ci sono sempre annunci.

Gli sviluppatori devono essere in anticipo su chi sosterrà il loro lavoro e da dove verranno i soldi. Eventuali modifiche devono essere comunicate agli utenti in modo chiaro e tempestivo per evitare shock e contraccolpi. Trasformare le persone in prodotti è un cambiamento etico da non prendere alla leggera. Affari pubblicitari loschi, reti pubblicitarie losche: dobbiamo stare attenti a come gestiamo la fiducia implicita dei primi utenti.

Dilemma etico n. 3: quanto vogliono essere liberi i contenuti?

Molte aziende dipendono dalla pubblicazione di contenuti senza pagare chi li crea. Alcuni si voltano e vendono annunci o addirittura fanno pagare per l'accesso. Queste aziende spesso non potrebbero sopravvivere e non potrebbero valutare il loro materiale in modo così attraente se dovessero sostenere la loro giusta quota dei costi di sviluppo. Sviluppano elaborate razionalizzazioni sulla "condivisione" o "fair use" per nascondere una decisione eticamente instabile.

Gli sviluppatori devono chiedersi come il loro codice supporterà tutti nella catena alimentare, dai creatori ai consumatori. Le persone che creano il contenuto vogliono che il loro lavoro sia distribuito in questo modo? Sono felici di lavorare per l'esposizione o l'attenzione da soli? Hanno una giusta quota delle entrate?

Non considerare queste domande equivale a chiudere un occhio sulla pirateria. Dopo tutto, non tutte le informazioni "vogliono essere libere".

Dilemma etico n. 4: quanta protezione è sufficiente

Alcuni dicono che tutto dovrebbe essere crittografato con due algoritmi diversi e bloccato in un disco rigido che viene conservato in una cassaforte. Purtroppo, l'overhead rallenta il sistema a una scansione e rende lo sviluppo 10 volte più oneroso. A peggiorare le cose, se un bit viene capovolto o una parte dell'algoritmo è sbagliata, i dati vengono persi perché la crittografia non può essere annullata.

Altri non vogliono alzare un dito per proteggere i dati. Il prossimo team può aggiungere una crittografia speciale in seguito, se necessario, potrebbero dire gli sviluppatori. Oppure potrebbero sostenere che non c'è nulla di sensibile al riguardo. I team che ignorano queste responsabilità sono generalmente in grado di generare un sacco di altro codice e creare pile di meravigliose funzionalità che le persone desiderano. A chi importa se sono al sicuro?

Non esiste una risposta semplice a quanta protezione applicare. Ci sono solo supposizioni. Di più è sempre meglio, finché i dati non vengono persi o il prodotto non viene spedito.

Dilemma etico n. 5: correggere o meno un bug?

È già abbastanza difficile negoziare le secche etiche quando coinvolgono decisioni attive, ma è ancora più difficile quando il problema può essere messo da parte ed etichettato come un bug che alla fine verrà risolto. Quanto dovremmo lavorare per risolvere i problemi che in qualche modo sono scivolati nel codice in esecuzione? Lasciamo tutto? Come decidiamo se un bug è abbastanza grave da essere corretto? 

Isaac Asimov ha affrontato questo problema molto tempo fa quando ha scritto le sue leggi sulla robotica e ne ha inserita una che vieta a un robot di non fare nulla se un essere umano fosse danneggiato dall'inazione del robot. Ovviamente i suoi robot avevano un cervello positronico in grado di vedere istantaneamente tutte le sfaccettature di un problema e risolverle. Le domande per gli sviluppatori sono così complicate che molti bug vengono ignorati e non risolti perché nessuno vuole nemmeno pensarci.

Un'azienda può dare la priorità all'elenco in modo equo? Alcuni clienti sono più importanti di altri? Un programmatore può riprodurre i preferiti scegliendo un bug piuttosto che un altro? Questo è ancora più difficile da contemplare quando ti rendi conto che è difficile prevedere quanto danno arriverà da un dato bug.

Dilemma etico n. 6: quanto codificare - o scendere a compromessi - per prevenire un uso improprio

La fotocamera Web Apple originale era dotata di un extra meccanico intelligente, un otturatore fisico che bloccava l'obiettivo quando era spento. L'otturatore e l'interruttore erano collegati insieme; non c'era modo di utilizzare la fotocamera senza aprire da soli l'otturatore.

Alcune delle webcam più recenti sono dotate di un LED che dovrebbe essere illuminato quando la fotocamera viene attivata. Di solito funziona, ma chiunque abbia programmato un computer sa che potrebbe esserci un punto nel codice in cui la telecamera e il LED possono essere disaccoppiati. Se è possibile trovarlo, la telecamera può essere trasformata in un dispositivo di spionaggio.

La sfida per l'ingegnere è anticipare l'uso improprio e progettare per prevenirlo. L'otturatore Apple è uno degli esempi ovvi ed efficaci di come può essere realizzato in modo elegante. Quando stavo lavorando a un libro sull'imbroglio al SAT, ho incontrato un hacker che stava aggiungendo software di rete alla sua calcolatrice. Dopo alcune riflessioni, ha deciso di supportare solo protocolli cablati perché temeva che i bambini avrebbero introdotto di nascosto una calcolatrice con Wi-Fi in un esame. Supportando solo protocolli cablati, ha assicurato che chiunque in un test avrebbe bisogno di collegare un cavo alla macchina del vicino. Odiava saltare i protocolli wireless, ma sentiva che il rischio di abusi era troppo alto.

Dilemma etico n. 7: fino a che punto difendere i clienti dalle richieste di dati

Se raccogli dati, è una scommessa sicura che un giorno la tua organizzazione sarà intrappolata tra servire i tuoi clienti e servire il governo. Le richieste di fornire dati a persone giuridiche stanno diventando sempre più comuni, lasciando sempre più organizzazioni di software e servizi a contemplare fino a che punto tradiranno la privacy dei propri clienti davanti alla legge. Puoi esaminare queste richieste e persino assumere i tuoi avvocati per contestare se sono veramente legali, ma la realtà è che i tribunali discuteranno delle questioni legali molto tempo dopo che i tuoi fondi si saranno esauriti.

Non ci sono soluzioni facili. Alcune aziende scelgono di lasciare l'attività piuttosto che mentire ai propri clienti. Altri stanno cercando di essere più aperti sulle richieste, che il governo spesso cerca di vietare.

Dilemma etico n. 8: come affrontare la natura internazionale di Internet

Internet corre ovunque, evitando molte delle tradizionali barriere ai confini. Questa può essere una ricetta per mal di testa legali quando i clienti A e B si trovano in paesi diversi. Questo è solo l'inizio, perché anche i server C e D si trovano spesso in paesi completamente diversi.

Questo porta a evidenti problemi etici. L'Europa, ad esempio, ha leggi severe sulla conservazione delle informazioni personali e considera le violazioni della privacy come fallimenti etici. Altri paesi insistono affinché le aziende mantengano copiosi registri sui rapporti. Quali leggi dovrebbe seguire un'azienda quando i clienti si trovano in paesi diversi? Quando i dati sono in contee diverse? Quando i dati vengono trasferiti attraverso linee internazionali?

Tenere il passo con ogni contingenza legale può essere erculeo, lasciando molte organizzazioni sicuramente tentate di seppellire la testa sotto la sabbia.

Dilemma etico n. 9: quanto restituire all'open source

Tutti sanno che l'open source è gratuito. Non paghi nulla e questo è ciò che lo rende così meraviglioso e complesso. Ma non tutti contemplano le questioni etiche che derivano dall'utilizzo di quel codice gratuito. Tutti i pacchetti open source vengono forniti con licenze e devi seguirli.

Alcune delle licenze non richiedono molti sacrifici. Licenze come la licenza Apache o la licenza MIT richiedono il riconoscimento e questo è tutto. Ma altre licenze, come la GNU General Public License, ti chiedono di condividere tutti i tuoi miglioramenti.

L'analisi delle licenze open source può presentare sfide etiche. Un manager di una grande azienda pubblica mi ha detto: "Non distribuiamo MySQL, quindi non dobbiamo nulla a nessuno". Stava puntando sulla clausola, scritta decenni fa, che legava gli obblighi della licenza all'atto di ridistribuire il software. L'azienda ha utilizzato MySQL per le sue app Web, quindi ha ritenuto che potesse durare senza restituire.

Non ci sono modi semplici per misurare gli obblighi etici e molti programmatori hanno sprecato molte battiture discutendo su cosa significassero. Tuttavia, l'intero sforzo si fermerà se le persone smettono di dare. La buona notizia è che spesso è nel migliore interesse di tutti contribuire perché tutti vogliono che il software rimanga compatibile con il loro utilizzo.

Dilemma etico n. 10: quanto monitoraggio è davvero garantito

Forse il tuo capo vuole assicurarsi che i clienti non stiano derubando l'azienda. Forse vuoi essere sicuro di essere pagato per il tuo lavoro. Forse un tizio inquietante del governo dice che devi installare una backdoor per catturare i cattivi. In ogni caso, l'argomento è pieno di assicurazioni che la backdoor sarà usata, come i poteri di Superman, solo per sostenere la verità e la giustizia. Non sarà usato contro i nemici politici o i meno fortunati. Non sarà venduto a regimi dispotici.

Ma cosa succederebbe se i cattivi scoprissero la porta nascosta e scoprissero come usarla da soli? E se la tua backdoor fosse usata per sostenere falsità e ingiustizie? Il tuo codice non può prendere decisioni etiche da solo. Questo è il tuo lavoro.

Dilemma etico n. 11: quanto dovrebbe essere davvero a prova di proiettile il codice

Certo, il calcolo minimo, la struttura dei dati semplice e l'approccio a forza bruta funzionano bene nella demo quando i problemi sono piccoli. Gli utenti provano il codice e dicono: "Accidenti, funziona velocemente". Diversi mesi dopo, quando una quantità sufficiente di dati è stata caricata nel sistema, compaiono i punti deboli dell'algoritmo economico e il codice rallenta a passo d'uomo.