Glen writes: < We've talked on list quite a bit about agency, hallmarks of living systems, complexity buzzwords like attractors, and far-from-equilibrium, etc. By treating software components as Kantian ends, rather than means, helps ensure *distribution* of computational effort/cost. Wrapping each component in its own ball of responsibility/duty/self-interest helps the designer play the game, on a long-term basis, of "logic, logic, where is the logic".
The traditional systems engineering approach attempts to distribute logic according to a modernist kind of planning the whole thing out, a waterfall process where you spend lots of upstream time planning, get a blueprint, parcel out effort to subcontractors, verify, test, deploy, maintain. This works, but not for long, and not for massive heterogeneous systems. > I think I'd prefer the analogy of a choir or an automated subway to boring division of labor. Nonetheless, Agile is a way to get a lot of (often junior) people involved in a project with bounded responsibility and to give them a sense of mastery. The emphasis is on simple, short (sub)contracts with transparency to the customer. There isn't much in the way of technical mastery, though, because the tasks to be accomplished are close to robotic and there is no Big Picture, just the periodic frantic consensus building -- I would argue consensus building for the sake of itself --- in contrast to the Kantian sort. Agile is one of those approaches that especially social people love because it is communication intensive and proliferates "Scrum masters" and other middle managers and mitigates the power of gurus. When the designer only has to consider local optimization to play the game and to take different roles in turn, it is not surprising that it is harder to achieve trust, global objectives, and efficiency. One gets a set of independent components that can be aggregated, but that aggregation may not have predictable properties in aggregate. I too would ridicule waterfall type approaches, but for a different reason. Waterfall type approaches put pompous know-it-alls in charge and delegate the "uninteresting" stuff to subcontractors. Or worse they bring several over-the-hill bosses into a room to rule by committee. As such individuals' technical knowledge and prowess is often dated, they make uninformed decisions and the delegated work needs to be redelegated over and over while they figure out why their Grand Plan didn't work out so well. IMO systems start to degrade when designers can't get the whole design and implementation in their head, and are reliant on other people for technical grounding. That's why government often doesn't work, and why we need AI. Marcus - .... . -..-. . -. -.. -..-. .. ... -..-. .... . .-. . FRIAM Applied Complexity Group listserv Zoom Fridays 9:30a-12p Mtn GMT-6 bit.ly/virtualfriam un/subscribe http://redfish.com/mailman/listinfo/friam_redfish.com archives: http://friam.471366.n2.nabble.com/ FRIAM-COMIC http://friam-comic.blogspot.com/
