> What we tend not to track down is the reason why software is the way it is.
The rest of your comment goes in a different direction, but still, you might be interested in the Big Ball of Mud essay:
> While much attention has been focused on high-level software architectural patterns, what is, in effect, the de-facto standard software architecture is seldom discussed. This paper examines this most frequently deployed of software architectures: the BIG BALL OF MUD. A BIG BALL OF MUD is a casually, even haphazardly, structured system. Its organization, if one can call it that, is dictated more by expediency than design. Yet, its enduring popularity cannot merely be indicative of a general disregard for architecture.
Thanks; it was good to reread those patterns. I wonder how the trajectory of say a life stage like http://www.laputan.org/lifecycle/lifecycle.html#Consolidate is affected if some or all of the people responsible for previous stages left in the interim.
The rest of your comment goes in a different direction, but still, you might be interested in the Big Ball of Mud essay:
> While much attention has been focused on high-level software architectural patterns, what is, in effect, the de-facto standard software architecture is seldom discussed. This paper examines this most frequently deployed of software architectures: the BIG BALL OF MUD. A BIG BALL OF MUD is a casually, even haphazardly, structured system. Its organization, if one can call it that, is dictated more by expediency than design. Yet, its enduring popularity cannot merely be indicative of a general disregard for architecture.
http://www.laputan.org/mud/