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(a)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(a)lists.wikimedia.org
https://lists.wikimedia.org/mailman/listinfo/wikitech-l
--
-george william herbert
george.herbert(a)gmail.com