> When it comes to speed, however, runtime speed isn't the only aspect of development to consider—you also have to consider development speed. It is not clear

> When it comes to speed, however, runtime speed isn't the only aspect of development to consider—you also have to consider development speed. It is not clear what sub-domain of the embedded-systems world this article targets. I read once somewhere that controlling equipment for nuclear stations is also embedded development. In general though, first and foremost, you will be considering the BOM cost -- how to reduce it, and how your software choices will impact it. Several strategies are possible: in the small-uC world, people start by developing on higher-end models, then optimise the size and speed as the product ships, to shoehorn the sw into a smaller, less expensive models. This is only possible if the cost of validation is not prohibitive (and if it is at all possible to re-validate the product again -- think about any possible re-certifications to do if the hw changes). If such re-validation is too costly or impossible, one will be cost-optimising the platform right from the start, and in general, cost of development -- an important factor (especially for those who has failed a product at least once ;-)) -- will come only in second to that.