A friend of mine decided to move from mechanical engineering into embedded firmware engineering. As I have watched him make this progression I realized that one could determine the stage an embedded firmware guy was at in project/career based on what they are cursing about. So I created the following graph.

Then I realized that for embedded projects this does not tell the whole story. That is for embedded firmware the design complexity is not constant for a project. So when we look at a project the design complexity for firmware grows over time, because this is the easiest to change. Hence we get a graph like this.

As you can see most projects start with the design complexity to be in electrical/hardware. This makes the firmware easier. However as a project goes along eventually management realizes they can not afford hardware costs and removes hardware requirements and try to push those requirements into firmware. That is for large volume production the cost of hardware is per unit, while the cost of firmware is free per unit. So it is cheaper to have one time development cost of firmware amortized over the production run, than it is to have continual hardware costs.

However keep in mind most projects never actually make it to production, because the development costs eventually exceed budgets. Here a lesson learned is that it is often best to put design features in hardware if possible, to reduce development time, then start production. If the sales volumes and projections justify another revision to reduce hardware costs (at expense of development time) then create a project to cost reduce hardware. Which means get to production even if the hardware costs are higher, cost reduce after you know you have market and sales.