I was reading the latest [IEEE]() Software and came across a piece by [Grady Booch](http://www.handbookofsoftwarearchitecture.com) that I wanted to capture here and reflect upon. The piece is mainly about his experience with systems that grow in complexity over time and the changes that need to be made in dealing with them as they mature through the normal application lifecycle.Grady uses examples ranging from information transmission systems (horse transmitted through to photon transmission) to the social network platform that is [FB](http://www.facebook.com). He comments that with the [growth](http://www.foxnews.com/scitech/2011/12/02/facebook-prepping-for-massive-hiring-spree) of FB comes problems keeping all of the development sane in an environment which is growing in complexity. He doesn’t make any outlandish claims of doom, but does recognize the fact that to manage this, things have to change at FB, because the developers can’t all fit into one war room any longer, let alone the wider code base which limits full grokability at all levels by all players. The architects will have abstracted much of the complexity to fit the big picture into their minds, and many of the devs will be unaware of what’s going on in the next room.
As he writes:
the moment you break a development organization across offices, you introduce communication and coordination challenges. Add the crossing of time zones, and unless you’ve got some governance in place, architectural rot will slowly creep in, interfaces will either ossify or blur, and the flaws in your dev culture will be magnified.
I have seen this in action myself, and believe that this is an important milestone in the growth of any organization hosting a codified solution to a problem. It’s true of an internal organization that grows large and/or quickly independently, let alone something like a [Community Source](http://en.wikipedia.org/wiki/Community_source) project that has to compete with all of the other [energies](http://www.nacubo.org/Business_Officer_Magazine/Magazine_Archives/July-August_2007/Mitigating_the_Risks_of_Big_Systems.html) / externalities entering the system of focus.
Just one other point, which is a Boody theory of what the conditions are for coder hard graft winning over system governance:
1. modest code base
2. absence of legacy friction
3. growth, acceptance, and limited competition that masks inefficiencies
4. hyperenergetic, manically focused group of developers
5. all of whom fit into a single war room for collaboration.
Looking at it from something like an organizational view, the complexity of all of the enterprise systems, including the big traditional three of HR, Finance and SIS, leaving aside the ones which are rising meteorically, including LMS, on-line media and lectures, facility management systems, library, VREs, etc., will all push the organizational conditions well outside the acceptable conditions for the Boody theory to hold. We must apply better governance to stand any chance of not imploding under our own weight, and most importantly, failing to be able to continue the innovation which is required by the organization to outcompete its stalkers.