Whether brute-force programming should actually be considered
stupid or not depends on the context; if the problem is not
terribly big, the extra CPU time spent on a brute-force solution
may cost less than the programmer time it would take to develop a
more `intelligent' algorithm. Additionally, a more intelligent
algorithm may imply more long-term complexity cost and bug-chasing
than are justified by the speed improvement.

Ken Thompson, co-inventor of Unix, is reported to have uttered the
epigram "When in doubt, use brute force". He probably intended
this as a {ha ha only serious}, but the original Unix kernel's
preference for simple, robust, and portable algorithms over
{brittle} `smart' ones does seem to have been a significant
factor in the success of that OS. Like so many other tradeoffs in
software design, the choice between brute force and complex,
finely-tuned cleverness is often a difficult one that requires both
engineering savvy and delicate esthetic judgment.

:brute force and ignorance: /n./ A popular design technique at
many software houses -- {brute force} coding unrelieved by any
knowledge of how problems have been previously solved in elegant
ways. Dogmatic adherence to design methodologies tends to
encourage this sort of thing. Characteristic of early {larval
stage} programming; unfortunately, many never outgrow it. Often
abbreviated BFI: "Gak, they used a {bubble sort}! That's
strictly from BFI." Compare {bogosity}.

:BSD: /B-S-D/ /n./ [abbreviation for `Berkeley Software
Distribution'] a family of {{Unix}} versions for the {DEC}