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 <[email protected]> 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 > [email protected] > https://lists.wikimedia.org/mailman/listinfo/wikitech-l > -- -george william herbert [email protected] _______________________________________________ Wikitech-l mailing list [email protected] https://lists.wikimedia.org/mailman/listinfo/wikitech-l
