Monday, November 13, 2006

Analysis paralysis and other fun design choices

Given we haven't picked out a cool acronym as a name, I can't say we've made HUGE progress. But we're getting there.

We're meeting once a week and have decided to use this as a "demo project" to work through project issues as well as being a boost to coding skills. And of course, that means we're dealing with the dreaded "R" word. Requirements. Gotta do em'.

So we tried to hash out what the "overarching architecture"
should look like. Got lost in philosophical rabbit
trails. Wondered where intelligence/data/processing should happen.

And then, after poking about some of 37signals manifesto, I came up for air and we REALLY need comprehensive BDUF requirements?

So we rethought a few things. Today's meeting looked like this:

Guiding design principles

  • encapsulation
  • loose coupling
  • build for extensibility...but keep things reasonable
(ed: isn't it great when you re-discover...oh yeah, that's why we do oo...)

Ways to go forward (breaking analysis paralysis)


  • What is the minimal requirements set needed to get the minimal functionality going?
  • Use "guiding design principles" where possible, use hard-and-fast
    requirements where necessary. (of course, "necessary" is always up for

  • Think "growing" software vs. "building" build in extensibility. Think "encapsulation/objects"...
  • Maybe a useful thought would be "how much encapsulation is
    reasonably necessary to re-use this module in another app?"...that
    might help with removing unnecessary dependancy on other modules too...

AR's (action required)

(sorry...old Intel-ism. I've just always thought AI should be artificial intelligence..)


  • build a basic robot with 2 axis of motion. (maybe 3rd axis would be ultrasonic sensor?)
  • Build a basic test-harness to move the robot through motion.


  • Begin experimenting with his USB cam and the motion sensing API
    at (check out
    his other articles for the image manipulation algo's used in the motion
    sensing kit..)

Both A and W

  • Remember that this is supposed to be FUN. If it starts being a CHORE and stops being FUN we need to re-eval... =^))

No comments: