Il sistema operativo LynxOS viene fornito completo degli strumenti necessari allo sviluppo di programmi in modo nativo, cioè senza fare uso di un computer diverso come piattaforma di sviluppo. Gli strumenti consistono in due compilatori C, uno sviluppato internamente dalla stessa Lynx, e uno derivato dal compilatore di pubblico dominio GNU gcc, un debugger simbolico (gdb), un editor (Emacs), e la serie di strumenti più o meno standard in ambiente UNIX (rcs, make, lint). Questo ambiente viene utilizzato all'interno del gruppo di visione dell'IRST per le applicazioni sviluppate sul robot a cominciare dal 1992, e a tutt'oggi se ne ha una buona cognizione dei pregi e delle carenze.
Al termine del progetto pilota GPOD (capitolo 
) è
stata fatta una valutazione dell'ambiente di sviluppo utilizzato sul
robot mobile.
L'analisi ha evidenziato che lo sforzo e il tempo necessario a manutenere, collaudare e correggere i programmi costituisce approssimativamente il 60-70% del tempo totale di sviluppo. Questi risultati coincidono con i dati normalmenti ottenuti per sistemi di sviluppo di tipo tradizionale [17].
Al fine di valutare in modo più oggettivo l'efficienza intrinseca dell'ambiente di sviluppo, e la sua idoneità allo sviluppo di moduli sensori per robot, ci si è avvantaggiati di aver fatto uso, durante lo sviluppo di GPOD, di uno strumento per il controllo delle versioni (RCS: revision control system ). RCS produce un file contenente le differenze tra una versione e la successiva, permettendo di recuperare le vecchie versioni. Le dimensioni del file di RCS corrispondono con buona approssimazione al totale del codice scritto prima di giungere alla versione definitiva del programma. L'indice utilizzato per valutare il sistema di sviluppo consiste nel rapporto tra le dimensioni del file di RCS e le dimensioni del programma definitivo corrispondente. Le dimensioni sono espresse in termini di linee o di numero di caratteri.
Il rapporto tra il codice totale e il codice definitivo è una variabile che dipende in modo complesso da molti fattori: esperienza col linguaggio di programmazione utilizzato, esperienza dello sviluppatore, conoscenza del problema, appropriatezza dell'ambiente di sviluppo al problema affrontato, ecc..
Tuttavia la costanza del rapporto su programmi diversi, sviluppati in
tempi diversi e quindi con diversi livelli d'esperienza, ci conforta
nel ritenerlo indicativo (vedi tabella ).
Dai dati risulta che, con il sistema di sviluppo basato sul linguaggio C, il codice che resta nella versione definitiva del programma è, in media, un quarto del codice totale scritto. Tuttavia programmi di una certa complessità possono raggiungere anche indici di 8, 9 o addirittura 16.
Table: Statistiche sulla produzione di codice per il
progetto GPOD. Le linee di codice totale sono state determinate
misurando le dimensioni del file RCS (il sistema automatico di
controllo delle versioni di UNIX). Malgrado il file contenga una certa
ridondanza, dando quindi un valore più alto rispetto al codice
effettivamente scritto, è rappresentativo del numero di revisioni
e modifiche alle quali il codice è stato sottoposto. Il rapporto
tra codice prodotto e codice definitivo è utilizzato come indice
dell'efficienza dell'ambiente di sviluppo.
Il linguaggio C non effettua nessun tipo di controllo durante l'esecuzione, questo rende estremamente difficile individuare gli errori di accesso alla memoria: errori negli indici degli array, accesso a oggetti non allocati, utilizzo di puntatori non inizializzati. Inoltre tutte le variabili (tranne quelle statiche) del linguaggio C non vengono automaticamente inizializzate alla creazione, ma contengono un valore casuale. La somma di queste caratteristiche fanno del C un linguaggio efficiente, ma di uso difficile.
La difficoltà e il tempo necessario a individuare gli errori costringono a modificare i programmi introducendo manualmente controlli, procedure di stampa delle variabili interne, direttive al precompilatore.
Tutto questo codice estraneo nasconde la logica del programma, rendendolo ``esteticamente'' insoddisfacente, e di difficile modifica.
Quando il programma viene considerato corretto gran parte dei controlli vengono rimossi. Tuttavia, spesso si presentano nuovi errori, e si rende necessario reintrodurre nuovamente il codice di verifica.