opening it up with Common Lisp

Favorite weblogs

Lisp Related

Bill Clementson

Finding Lisp

Lemonodor

Lispmeister.com

Planet Lisp

Politics

Orcinus

Talking Points Memo

This Modern World

Working for Change

Other home

Polliblog

Recent Readings

Book review: Darwinia
Reviewed: Friday, August 11, 2006

Summer reading: Spin
Reviewed: Saturday, August 5, 2006

Runner
Reviewed: Tuesday, July 18, 2006

the Omnivoire's Delimma
Reviewed: Wednesday, July 12, 2006

the Golem's Eye
Reviewed: Wednesday, May 31, 2006





tinderbox
 width=

Software and Normal Accidents
Friday, March 18, 2005

Just found some random notes taken back when I was reading Normal Accidents. That book covers mostly physical systems where coupling occurs via spatial or temporal proximity and where failures arise via hidden and unwanted connections. Perrow's ideas apply to software too though the immediate connections are a bit tenuous: we have coupling, we have common systems, we have large systems, we have hidden and unwanted connections. So what are the normal accidents waiting to happen in our software systems. One type arises from overwhelming complexity. As Perrow says when discussing nuclear attack warning systems:

It is an interesting case to reflect upon: at some point does the complexity of a system and its coupling become so enormous that a system no longer exists? ... We cannot be sure that it really constitutes a viable system. It just may collapse in confusion!

I think a more interesting line of attack comes from our desires to refactor and find the common routines. We all know the feeling of a subroutine or function trying to do too much, the sickness of a routine pulled in different directions as a system evolves. To me, this is one of the positive aspects of the Feyerabend project: as systems grow, we can no longer hope to achieve crystalline purity. Instead, we need to find an organic architecture that tolerates diversity and error.

Finally, I think it might be interesting to think of software development as as transformative process (though I admit to not being quite clear what we are transforming into what!). If it is, then what do we monitor to maintain the process? Checkins and Checkouts? Number of changes? Bugs corrected and added? Number of function points? Number of tests? What else.

If anyone has ideas about this, please let me know.


|

Home | About | Quotes | Recent | Archives

Copyright -- Gary Warren King, 2004 - 2006