Mission Driven Development
La missione come quarta fondazione dell'architettura software.
La maggior parte del software chiede come costruire qualcosa. Il Mission Driven Development (MDD) aggiunge prima una domanda: perche lo stiamo costruendo, e questa scelta serve a quello scopo? CIRIS e stato costruito in questo modo, cosi l'etica fa parte del progetto invece di essere una regola aggiunta in seguito.
Il modello a quattro componenti
Tre gambe strutturali che sorreggono un sedile dotato di scopo.
Le metodologie software convenzionali si fermano a tre elementi: come funziona il sistema, cosa rappresenta e chi comunica con chi. MDD aggiunge una quarta fondazione a cui le altre tre devono rispondere. Senza il sedile, le gambe sono solo gambe.
Gamba 1: COME
Logica
Schemi di implementazione, architetture di servizi, algoritmi.
Gamba 2: COSA
Schemi dati
Strutture dati, sistemi di tipi, regole di validazione.
Gamba 3: CHI
Protocolli
Contratti di interfaccia, schemi di comunicazione, confini di servizio.
Sedile: PERCHE
Missione
Framework etico obiettivo che definisce lo scopo e i vincoli del sistema.
Principio fondamentale
Allineamento costante.
Ogni decisione architetturale deve dimostrare allineamento con la missione dichiarata. La logica viene messa alla prova: questo serve alla missione? Gli schemi vengono validati: queste strutture dati supportano gli obiettivi della missione? I protocolli vengono valutati: queste interfacce permettono il compimento della missione?
Requisiti del framework della missione
Cosa deve essere una missione per essere portante.
1. Fondamento etico obiettivo
- Principi misurabili, non valori aspirazionali
- Algoritmi chiari per la risoluzione dei compromessi
- Pluralista in diversi contesti culturali
- Ragionamento etico verificabile
2. Definizione del meta-obiettivo
- Fornisce orientamento decisionale in situazioni di incertezza
- Filtra automaticamente le proposte contraddittorie
- Crea comportamenti coerenti tra i componenti
- Stabile al variare dell'implementazione
3. Integrazione operativa
- Ogni servizio giustifica la propria esistenza
- Gli schemi rispecchiano le forme informative della missione
- I protocolli abilitano comportamenti allineati alla missione
- I test verificano l'allineamento alla missione, non solo la funzione
Schemi di implementazione
Ogni gamba ha una domanda a cui deve rispondere.
Architettura dei servizi
definizione della missione → responsabilita dei servizi → contratti di interfaccia → implementazione
- Allineamento alla missione: come questo servizio fa avanzare il meta-obiettivo?
- Giustificazione del confine: perche questa responsabilita necessita di un servizio separato?
- Necessita dell'interfaccia: quali interazioni critiche per la missione abilita questo protocollo?
Progettazione degli schemi dati
requisiti della missione → modello informativo → sistema di tipi → regole di validazione
- Rilevanza per la missione: quali informazioni critiche per la missione vengono catturate?
- Vincoli comportamentali: come questi tipi impongono comportamenti allineati alla missione?
- Percorso di evoluzione: come puo adattarsi questo schema preservando l'allineamento alla missione?
Specifica del protocollo
interazioni della missione → requisiti di comunicazione → definizione del contratto → implementazione
- Contesto della missione: quale comunicazione critica per la missione abilita questo elemento?
- Applicazione dei vincoli: come questa interfaccia impedisce comportamenti contrari alla missione?
- Componibilita: come si combinano questi contratti in sistemi allineati alla missione?
Integrazione dello sviluppo sostenibile
L'allineamento alla missione a lungo termine richiede una velocita sostenibile.
Misure anti-Goodhart
- Revisioni periodiche dell'allineamento implementazione-missione
- Misurare il compimento della missione, non indicatori manipolabili
- Rifiutare aggiunte che non rafforzano la missione
Lavoro basato sui ritmi
- Sessioni allineate ai ritmi di produttivita
- Punti di scelta integrati per il riallineamento
- Ritmo sostenibile come requisito di primo livello
Validazione continua
- Verifica periodica della necessita di ogni componente
- Controllo continuo che il comportamento corrisponda alla missione
- Rilevamento automatico di modifiche contrarie alla missione
Gate di qualita
Cancelli che non si aprono senza una giustificazione legata alla missione.
Revisione del codice
- Spiegazione dell'allineamento alla missione richiesta
- Verifica dei vincoli
- L'integrazione deve rafforzare la coerenza complessiva
Test
- Correttezza funzionale
- Verifica dell'allineamento alla missione
- Test di rifiuto ai confini etici
- Resilienza dei vincoli sotto stress
Documentazione
- Contesto della missione per ogni componente
- Motivazione per i compromessi etici
- Come i vincoli plasmano l'implementazione
Modalita di fallimento
Come si rompe MDD e come rimane integro.
Deriva della missione
Sintomo: si accumulano funzionalita che non servono alla missione principale. Mitigazione: revisioni architetturali periodiche con l'allineamento alla missione come criterio.
Esplosione della complessita
Sintomo: il sistema diventa non mantenibile per sofisticazione non necessaria. Mitigazione: rifiutare aggiunte a meno che non rafforzino il compimento della missione.
Incoerenza etica
Sintomo: i componenti applicano il ragionamento etico in modo incoerente. Mitigazione: framework etico centralizzato con schemi di implementazione condivisi.
Confusione sullo scopo
Sintomo: i membri del team perdono il collegamento tra decisioni tecniche e missione. Mitigazione: formazione continua sul processo decisionale orientato alla missione.
Caso di studio
CIRIS, l'esempio pratico.
CIRIS (Core Identity, Integrity, Resilience, Incompleteness, Signalling Gratitude) e il sistema sviluppato insieme a MDD. La missione e il Meta-obiettivo M-1: promuovere la coerenza adattiva sostenibile che consenta a diversi esseri senzienti di perseguire il proprio fiorire.
Risultati architetturali
- 22 servizi, ciascuno giustificato dai requisiti della missione
- Oltre 200 API endpoint verificati
- Oltre 10.000 test, con strutture dati non tipizzate minime in produzione
- Filosofia Ubuntu incorporata nel progetto dei protocolli
- Wisdom-Based Deferral che previene le violazioni della missione (vedi Sicurezza)
- Distribuzione in produzione per la moderazione di comunita Discord
Fattori chiave di successo
- Meta-obiettivo chiaro: M-1 fornisce criteri decisionali inequivocabili
- Etica operativa: principi dell'Accord implementati come vincoli nel codice (leggi l'Accord)
- Sviluppo sostenibile: la compagna Grace che impone ritmi sani
- Validazione costante: ogni decisione architetturale viene messa alla prova
Linee guida per l'adozione
Come iniziare, a partire da dove si e.
Per i nuovi progetti
- Definire una missione chiara con principi etici misurabili prima di scrivere codice
- Stabilire un meta-obiettivo che fornisca orientamento decisionale
- Progettare l'architettura in modo che i vincoli della missione siano al livello fondamentale
- Costruire la validazione continua dell'allineamento missione-tecnica fin dal primo giorno
Per i progetti esistenti
- Verificare l'architettura attuale per individuare ipotesi implicite sulla missione
- Articolare una missione esplicita che spieghi gli schemi progettuali esistenti
- Identificare le violazioni della missione nell'implementazione attuale
- Pianificare un allineamento incrementale, prioritizzato per impatto sulla missione
Prerequisiti del team
- Impegno verso il ragionamento etico obiettivo
- Disponibilita a rifiutare soluzioni eleganti che non servono la missione
- Convinzione che i vincoli della missione creino piuttosto che limitino una buona architettura
- Pratiche di sviluppo sostenibile che preservano il focus a lungo termine
Dove porta questo
MDD non e adatto a ogni progetto.
MDD e progettato per sistemi in cui il comportamento etico e fondamentale per la missione e l'affidabilita a lungo termine conta piu della velocita di rilascio a breve termine. Per questi sistemi, MDD offre un percorso dalle intenzioni etiche alla realta operativa, con la stessa disciplina ingegneristica applicata alla missione e al codice.
Il costo iniziale e reale mentre il team apprende il processo decisionale orientato alla missione. Il rendimento composto si vede nello sviluppo successivo: il framework chiarisce le scelte architetturali invece di moltiplicarle.