Scrum: Subsumption Architecture and Emergent Behavior
PicBot exhibiting emergent behavior
Yesterday's posting on the birth of Scrum generated some questions on Rodney Brooks' subsumption architecture. One could argue that Agile processes emerge architectures by building the simplest possible thing and evolving into more complex behavior by implementing close connection of developers to code, pre-organized patterns of behavior, simple refactoring techniques, no central control, no shared representation, and short daily meetings with face to face communications.
This sounds remarkably similar to the University of Michigan AI Lab Cliff Notes on Rodney Brooks:
Brooks reasons that the Artificial Intelligence community need not attempt to build "human level" intelligence into machines directly from scratch. Citing evolution as an example, he claims that we can first create simpler intelligences, and gradually build on the lessons learned from these to work our way up to move complex behaviors.
Brooks' Subsumption architecture was designed to provide all the functionality displayed by lower level life forms, namely insects. Using a common house fly as an example, Brooks claims that creatures at this level of intelligence have attributes such as close connection of sensors to actuators, pre-wired patterns of behavior, simple navigation techniques, and are "almost characterizable as deterministic machines". The Subsumption architecture provides these capabilities through the use of a combination of simple machines with no central control, no shared representation, slow switching rates and low bandwidth communication.
2 Comments:
Emergent Architecture is becoming a hot topic! The argument in favour usually refers to the fact that requirements change etc so why do a big up-front design. The opposite opinion is that not all projects are created equal, and that some projects although complex in nature do by their nature have a simple requirement. e.g. a code conversion from perl to C++ to make somthing faster - but with the same functionality rests almost entirely on a non-functional requirement. I have tried to wrap my head around this one in my Blog - maybe you can open up the debate further?
http://www.scrumlabs.com/2008/07/emergent-architectiture-yes-or-no/
Some work on architecture belongs with preparing the Product Backlog for a Sprint. Certain decisions need to be made and they should be good ones based on extensive development in the domain whenever possible. How much architecture? Just enough. I asked Jim Coplien how much work is needed to start a Sprint by experienced architects and his comment was "no more than a week." At PatientKeeper, a few days writing on the back of napkins was enough to launch one of the best architected applications in healthcare. Of course it took many years to evolve that architecture yet it still reflects the original component design.
Post a Comment
<< Home