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.