Descrive uno stile di programmazione primitivo, uno in cui il programmatore si affida alle capacità di elaborazione del computer invece di usare la propria intelligenza per semplificare il problema, spesso ignorando i problemi di scalabilità e applicando metodi semplici che si adattano a problemi piccoli direttamente a quelli grandi. Il termine è anche usato in relazione allo stile di programmazione: i programmi brute-force sono scritti in un modo pesante e noioso, pieno di ripetizioni e privo di ogni eleganza e astrazione utile (Vedi anche brute force and ignorance).
L'esempio canonico di un algoritmo brute-force è associato con il ‘problema del commesso viaggiatore’ (TSP), un classico NP-hard problem: Immagina una persona che si trova, mettiamo, a Boston, e vuole arrivare in macchina in un numero N di altre città. In qualche ordine dovrebbe visitare le città per minimizzare la distanza di viaggio? Il metodo brute-force consiste semplicemente nel generare tutte le possibili strade e confrontare le distanze; mentre esso è una garanzia di funzionamento ed è semplice da implementare, è davvero stupido poichè considera anche le strade ovviamente assurde (come andare da Boston a Houston passando per San Francisco e New York, in ordine). Per poche città funziona bene ma subito diventa inefficiente quando N aumenta (per N = 15, ci sono ancora 1,307,674,368,000 possibili percorsi da considerare, e per N = 1000 — beh, vedi bignum). A volte, sfortunatamente, non ci sono migliori soluzioni. Vedi anche NP- e rubber-hose cryptanalysis.
Un esempio più sciocco di programmazione brute-force è trovare il numero più piccolo in una grande lista prima usando un altro programma per ordinare la lista in ordine ascendente, e poi per prendere il primo numero.
Se la programmazione brute-force debba essere realmente considerata stupida o no, dipende dal contesto; se il problema non è terribilmente grande, il tempo di CPU in più speso su una soluzione brute force può costare meno del tempo del programmatore che vorrebbe sviluppare un algoritmo più ‘intelligente’. In più, un algoritmo più intelligente potrebbe implicare costi maggiori di complessità e di rilevazione degli errori che sono giustificati dal miglioramento di velocità.
Ken Thompson, co-inventore di Unix, è citato per aver pronunciato l'epigramma “Quando sei in dubbio, usa il brute force”. Probabilmente intendeva questo come un ha ha only serious, ma la preferenza dell'originale kernel Unix per algoritmi semplici, robusti e ‘portabili’ piuttosto che quelli fragili e furbi sembra esser stato un fattore significativo per il successo di quell'OS. Come in molti altri negoziamenti nella progettazione software, la scelta fra brute fource e intelligenza complessa e fine è spesso difficile e richiede sia esperienza nell'ingegneria sia giudizi estetici delicati.