Don't take this too seriously, except for the bit in bold.
- Spend time on making your metaphors and interfaces clear.
- Descriptions of things optimised for the
80% of programmers are preferable to those with only the top 20% will
understand. If this seems "dumbing down", consider that it is often
harder to describe something complex simply, than to describe something
simple in a complex fashion.
- Try to make decisions that can work in other languages. Kamaelia is only implemented right now in python, but the principles must be portable.
- Remember that a key aim is to make life
easier for the bulk of programmers, with a recognition that its worth
optimising for maintenance.
- Fun descriptions, ideas and code tend to win arguments :-)
- You're going to get it wrong. Whether you like it or not,
something you do will go wrong and be very wrong. We'd like to aim for
a very high hit rate of "good" decisions, but often the only way to
find out what the "right" answer is to actually try something and find
out. Please don't be afraid of pointing out the emperor has new
clothes. We might be embarrassed (possibly even upset) for a while, but
we'd rather be told and know when we've got something wrong. We're
human too after all :-) For a good discourse on why it's worth taking
this risk, read Paul Arden's excellent (and brief!) read "Whatever you
think, think opposite".
- A corrollary of this is that it might
make sense occasionally to do sketches and branches of ideas that you
think are really bad ideas and see how they pan out!
- Implementations change, but interfaces stay the same. If
the interfaces change, you've written something new. ie you may add new
inboxes and outboxes to components, but if you change behaviours of
existing in-/out-boxes you should consider whether you're actually
writing something new. If in doubt, talk to the team.
- Quick, simple, clear, justified decisions (But not hasty).
- All rules have exceptions.
- import this :-) (and that and theother)