The problem is that "quick and dirty" seldom means "quick and cheap." In fact, the two are generally diametric opposites. Doing things with not enough analysis before design generally means not as quick as desired, though perhaps quick enough, and VERY dirty, not to mention costly.

As Erik has often pointed out, saving a few cents, or even dollars, on a product with a production volume under 100 units is "carrying coals to Newcastle." However, using a controller provisioned and capable of working with SDRAM, which would cut board size and cost, so that it supports, say 256 MBytes of code when 20kBytes would do, is not that smart, even if it is relatively similar in cost, since it tempts the programmer to use sloppy and inefficient techniques that consume the lion's share of the available resources despite the fact he only requires 1% of them. The example of PC is a good one. There are programs for Windows, for example, that require well over 5 MBytes of code to do what their DOS predecessor accomplished in a small fraction of the time on a MUCH slower CPU with <20 kB of code. Without going into detail about where this "growth" comes from, I can believe quite easily that it comes largely from lack of focus on simple measures of efficiency.

RE