This post originated from an RSS feed registered with Agile Buzz by Keith Ray. Original Post: Quick Stuff Feed Title: MemoRanda Feed URL: http://homepage.mac.com/1/homepage404ErrorPage.html Feed Description: Keith Ray's notes to be remembered on agile software development, project management, oo programming, and other topics. Latest Agile Buzz Posts Latest Agile Buzz Posts by Keith Ray Latest Posts From MemoRanda

Tell, don't ask. Keep this slogan in mind when doing object-oriented programming. Doing this assiduously results in good OO designs. Quick example:

// BAD: asking another object for its values 
// and then computing something with those values.

float w = rect.width();  // ASK for width
float h = rect.height(); // ASK for height
float area = w * h;      // compute area
println( "you will need " + area + " square meters of fabric" );

// GOOD: tell the other object what you want, and
// it figures out how to do it.

float area = rect.area();  // TELL me the area
println( "you will need " + area + " square meters of fabric" );

Buddhism says that "ego" is something we make up, and thus have to constantly work to maintain it. This blog entry by Adrian Savage applies that understanding to leadership:

"Ego and egotism are fatal to good leadership. They cause over-optimism, over-confidence and arrogance. They inflate people into domineering monsters focused on petty personal victories, wreck relationships and encourage leaders to take on too much [...]"

Johanna Rothman points us to 100 rules for project management. I quote a couple of rules that relate to Ego:

Rule #11: Never try to get even for some slight by anyone on the project. It is not good form and it puts you on the same level as the other person and, besides, probably ends up hurting the project getting done.

Rule #12: Don't get too egotistical so that you can't change your position, especially if your personnel tell you that you are wrong. You should cultivate an attitude on the project where your personnel know they can tell you of wrong decisions.

Rule #28: People who monitor work and don't help get it done never seem to know exactly what is going on (being involved is the key to excellence).

Rule #63: Software has now taken on all the parameters of hardware (i.e., requirement creep, high percentage of flight mission cost, need for quality control, need for validation procedures, etc.). It has the added feature that it is hard as blazes to determine it is not flawed. [...]

I tossed in rule 63 to remind us in the software business that feature-creep was around in the days of "mostly hardware". And it needed testing and validation then just as software needs testing and validation now.