从历史上看，嵌入式开发系统非常简单：只有几K内存的8位CPU。尽管这种简单的系统仍在开发中，但许多资源丰富的设备现在都在使用一个或多个32位处理器和许多兆字节的内存。这些设备的巨大威力导致软件的规模和复杂性不断增加。但这种复杂性的极限是什么?

　　如果我们观察机械系统，就会发现存在很多复杂性。迄今为止最复杂的机器是航天飞机轨道器，它有一百万个运动部件。考虑到这些车辆在设计上有多大的挑战，它们工作得非常好。我想，没有内在的原因不能创造出更复杂的机器。

　　现在，电子系统逐渐变得更加复杂和小巧。在20世纪50年代，嵌入式开发一个复杂的电子设备可能有100个(分立的)晶体管——它甚至可能使用真空管。到今天，芯片上有几十亿个晶体管并不罕见。芯片的几何形状每年都会缩小到越来越小的纳米。

　　在过去50-60年中，软件复杂性急剧增长，反映了硬件的进步。比特是软件的最小“单位”，以这种方式衡量，软件的复杂性已经远远落后于机械设计，它比硬件领先一到两个数量级。然而，我们看不到软件理论复杂性/规模的任何具体限制。制造大内存芯片已经足够容易了，所以我们可以让代码越来越大。

　　当然，设计是瓶颈。硬件设计非常具有挑战性，需要复杂的电子设计自动化(EDA)。嵌入式开发中软件开发更难一些。但它需要的不仅仅是工具。

　　在生活的几乎所有方面(包括嵌入式软件)，基本上有三种方法来应对更大的挑战：

　　1.更加努力地工作(即更多的人力)

　　2.工作更长时间

　　3.更聪明地工作

　　有时第1种和第2种可以互换。例如，在建筑工程中，更多的劳动力可能会加快工作进度。但是，如果仅仅指派更多的人员来完成这项工作，软件开发的回报就会迅速减少。这在很大程度上是因为代码不同部分之间的相互关系，以及开发人员进行通信的相应需求。他们最终花在沟通上的时间超过了编码。在某种程度上，开发团队的智能扩展可以带来好处。这需要确定具体的专门知识要求，并相应地指派工作人员。这与嵌入式开发尤其相关，其中的专业领域可能是：应用程序级代码、驱动程序开发、操作系统配置、网络、UI设计等。

　　更聪明地工作听起来像是一家公司的口号，但意思是让开发人员能够在给定的时间段内创建和调试更多的功能。大体上，有两种方法：

　　更高抽象级别的代码

　　重用现有代码(并使代码可重用)

　　更高层次的抽象意味着远离传统语言，如C语言，并接受其他范例。UML是一种可能性。可重用代码在很大程度上是面向对象编程(OOP)技术的领域。可以创建可重用的对象，OOP支持专业知识的封装，这对于嵌入式开发来说也是特别有用的。