From http://www.artima.com/weblogs/viewpost.jsp?thread=362327 :
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.
On Wed, Apr 22, 2015 at 10:45 AM Ori Livneh ori@wikimedia.org wrote:
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.
I remove features from MediaWiki all the time. I think the number of new additions outpaces my removals though :p
-Chad
Hi!
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.
Apple is doing it from time to time, and is not shy about it. I'm not sure I personally am a big fan, but it works for many people.
Another interesting take on the same topic from ESR: http://esr.ibiblio.org/?p=6737
I'm a fan of removing features when the feature is not currently done well and we aren't going to do it well anytime soon, if ever. Products with fewer high quality features are superior in many ways to products with many low quality features.
- Trevor
On Wednesday, April 22, 2015, Stas Malyshev smalyshev@wikimedia.org wrote:
Hi!
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.
Apple is doing it from time to time, and is not shy about it. I'm not sure I personally am a big fan, but it works for many people.
Another interesting take on the same topic from ESR: http://esr.ibiblio.org/?p=6737
-- Stas Malyshev smalyshev@wikimedia.org javascript:;
Wikitech-l mailing list Wikitech-l@lists.wikimedia.org javascript:; https://lists.wikimedia.org/mailman/listinfo/wikitech-l
Merely removing features is not deep enough. This is fundamentally at its origins an architecture challenge, and a development management challenge. Removing features is rearguard action, not properly conceived engagement with the problem.
Complexity can be neutral; code size by itself is not horrible in an era of TB drives. But code size hides bugs, and security flaws, and exponentially more complicated development challenges the more components and parts that one must consider interacting with each other.
ESR was wrong; he's asserting that simplicity is too hard and we should give up. We can't give up; software projects and distros / OS versions that get too complex become unsustainable and fail in the market (public opinion, or just financially). He does not seem to understand the harm of complexity, and does not here appear to understand the role that singular architects and dev leaders and style guides and code standards can have. A very few people, or one, can point a project in a direction that both allows lots of participation AND remains focused and architecturally clean.
PHK wasn't entirely right; he's gotten down in the weeds on a much larger problem, and the weeds distracted everyone. But he has a point.
On Wed, Apr 22, 2015 at 1:26 PM, Trevor Parscal tparscal@wikimedia.org wrote:
I'm a fan of removing features when the feature is not currently done well and we aren't going to do it well anytime soon, if ever. Products with fewer high quality features are superior in many ways to products with many low quality features.
- Trevor
On Wednesday, April 22, 2015, Stas Malyshev smalyshev@wikimedia.org wrote:
Hi!
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.
Apple is doing it from time to time, and is not shy about it. I'm not sure I personally am a big fan, but it works for many people.
Another interesting take on the same topic from ESR: http://esr.ibiblio.org/?p=6737
-- Stas Malyshev smalyshev@wikimedia.org javascript:;
Wikitech-l mailing list Wikitech-l@lists.wikimedia.org javascript:; https://lists.wikimedia.org/mailman/listinfo/wikitech-l
Wikitech-l mailing list Wikitech-l@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/wikitech-l
On 15-04-22 05:06 PM, George Herbert wrote:
He does not seem to understand the harm of complexity, and does not here appear to understand the role that singular architects and dev leaders and style guides and code standards can have.
I'm pretty sure I disagree with this. Any system will begin to show emergent complexity past a certain size or scope, and no amount of precise architecture can prevent it.
A good architecture team, style guides and code standard are all beneficial in that they push what 'certain size' is further, and helps mitigate the effects of increasing complexity so that it remains more managable - but they do not prevent either.
No matter how well designed, any system will exponentially diverge from expectations and show emergent behaviour as the number of interacting component grows. That is an inevitable reality, no matter how insightful the project lead or how stringent the process.
-- Marc
At those sizes, insisting on APIs between component levels/layers/areas helps keep sanity and order.
Every system's complexity reflects both actual functional requirements, at whatever level of simplicity was realistic to impose, and evolution of the required features as the uses were expanded and understood better. If you planned for orderly solutions and approaches at a higher level of complexity than you had to implement to start with, expecting that growth, then the evolving product can maintain a reasonable organized approach.
The question is, what was the forseen growth, the margins for that, and the eventual growth level. With many internet things, forseen growth was 10x and the eventual growth seems to be bimodal into a lot of items at around 2x and a very few very successful ones at 100x.
It *is* a perfectly valid question as to whether enough time and architectural experience is available to pre-plan a new internet tool for the potential 100x growth...
(This does argue for complete rearchitect/recode projects every so often for very large successful tools...).
On Wed, Apr 22, 2015 at 3:17 PM, Marc A. Pelletier marc@uberbox.org wrote:
On 15-04-22 05:06 PM, George Herbert wrote:
He does not seem to understand the harm of complexity, and does not here appear to understand the role that singular architects and dev leaders and style guides and code standards can have.
I'm pretty sure I disagree with this. Any system will begin to show emergent complexity past a certain size or scope, and no amount of precise architecture can prevent it.
A good architecture team, style guides and code standard are all beneficial in that they push what 'certain size' is further, and helps mitigate the effects of increasing complexity so that it remains more managable - but they do not prevent either.
No matter how well designed, any system will exponentially diverge from expectations and show emergent behaviour as the number of interacting component grows. That is an inevitable reality, no matter how insightful the project lead or how stringent the process.
-- Marc
Wikitech-l mailing list Wikitech-l@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/wikitech-l
On 04/22/2015 01:44 PM, Ori Livneh wrote:
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."
+1. Related concept: https://blog.intercom.io/product-strategy-means-saying-no/ .
Obviously, it's really about knowing when to say Yes, and when to say No, but both are very important.
Matt Flaschen
wikitech-l@lists.wikimedia.org