That software systems are getting bigger and more pervasive is testament that we can at times muster the wherewithal to manage the inherent complexity of constructing large systems. At other times, however, it simply supports the view that creating complexity is far easier than hiding it — the creeping featurism, physical size, and bugginess of certain operating systems and wordprocessing packages is tantamount to a public admission of software engineering failure. To paraphrase Blaise Pascal, "The software to solve your problem is larger and more complex than necessary, because we did not have the ability or resources to make it smaller and simpler." [...] In other words, leaving or taking things out by constantly examining the difference between inherent and actual complexity, questioning and reducing the number of features, and questioning and reducing the amount of code. For benighted management that still measures productivity in terms of KLOCs, this is scary: it appears to represent negative productivity. But... less code, fewer bugs... fewer features, greater ease of use... and so on. This leads to an interesting marketing possibility, and one that I have seen in action only a few times: the idea that a subsequent release of a product might be smaller or have fewer features than the previous version, and that this property should be considered a selling point. Perhaps the market is not mature enough to accept it yet, but it remains a promising and classic ideal — less is more.