Come distinguere tra software banale e non banale? [chiuso]

Sto per uscire su un ramo qui e dire:

A trivial program is one that does not directly impact the business.

Una società di produzione considererebbe banale il suo software di contabilità, ma il software che controlla il braccio robotico che muove l'acciaio bollente è fondamentale. Possono occuparsi di bug e di inversione di tendenza nel primo, ma non di quest'ultimo. Se c'è un problema, è necessario che sia corretto ora .

Credo che l'intenzione più comune di questa affermazione sia che un programma abbia le seguenti caratteristiche:

• È piccolo.
• Breve durata.
• Non c'è bisogno di ulteriore estensione.
• Un solo sviluppatore.

Buttandolo via completamente, binari e fonti. Se qualcuno nota, non è stato banale.

Trivial is ...

• qualcosa che esiste già, quindi perché reinventare la ruota?
• qualcosa che può essere facilmente costruito mediante lo scripting di alcuni altri programmi insieme o la scrittura di un piccolo codice che fa un uso pesante delle librerie esistenti che fanno ciò che deve essere fatto.
• qualcosa che uno studente medio di laurea in CS potrebbe svolgere come compito a casa da piccolo a medio.
• qualcosa che ha dettagli dettagliati che potrebbero facilmente adattarsi a un tovagliolo da cocktail.
• qualcosa che potresti codificare mentre sei distratto / ubriaco / nel tempo libero di blocchi di 4 o 5 minuti.
• qualcosa che potrebbe essere creato con un semplice strumento di generazione del codice.

In un ambiente aziendale, aggiungerei questi:

• qualcosa a cui gli utenti aziendali non si preoccupano di aspettare un po 'di tempo per una correzione.
• qualcosa usato internamente che non ha supporto ufficiale dall'IT.
• qualcosa che ha la priorità tra le priorità più basse da parte del Business, quando si eseguono la pianificazione e la pianificazione delle risorse.

Definirei un programma banale come uno che potrebbe essere ragionevolmente codificato:

• In una sola seduta.
• Come singolo file / modulo (supponendo che tu non stia programmando in Java o in un linguaggio che costringa alla divisione di moduli a grana fine)
• Da qualsiasi programmatore "tuttofare", piuttosto che uno specialista.

Ecco i miei esempi di programmi "banali":

1. Un progetto "fittizio" che ho impostato e che ha iniziato la codifica solo per provare un pezzo di tecnologia o codice di esempio. Nessuna intenzione di essere schierata o mostrata a nessuno.
2. Codice demo scritto per presentazioni tecniche.
3. Un "one-off". Intendo una rapida applicazione che dovevo creare una volta, perché è una strana situazione di dati che è stato necessario spostare in un certo modo, o qualcosa che verrà immediatamente sostituito da qualcosa di più permanente.

Il software Trival non esiste, è quando senti i requisiti e le cose che saranno trival quando in realtà è sempre non-trival

Ecco una citazione che ho visto su Usenet una decina di anni fa, è ancora più rilevante ora.

Complexity of a Software Solution is inversely proportionate to the complexity of the explanation of what it should do. - Unknown

Un programma che è solo un mucchio di metodi getter / setter. Nessuna logica di programmazione. Forse qualcosa con pochi loop.

Questa è la mia definizione di banale.

La nostra definizione di lavoro è "qualcosa che non dipende da nient'altro".

Sfortunatamente ci sono stati alcuni prototipi banali che sono diventati prodotti di produzione non banali.

L'ho anche sentito utilizzare nel contesto dell'impatto del programma sulla pianificazione generale del progetto. Se una determinata specifica non modifica la tempistica di consegna del prodotto, rientra nell'etichetta di banale.

Conoscevo un programmatore che tendeva a usare "banale" come sinonimo di "Neanche vale la pena discutere".