About
Exploring Solution Spaces, Keith Ray's blog on Software development and other topics.
Send comments to:
keithray@mac.com
| For Agile Training, eLearning, or Coaching contact: |
| Industrial Logic, Inc. |
| 866-540-8336 (toll free) |
| 510-540-8336 (Berkeley, California) |
| Links |
| xpminifaq |
| Résumé |
| “Adopting XP” Article 2002 (pdf) |
| “ Refactoring” Article 2006 |
| AYE Conference |
| Lucien W. Dupont |
| Elisabeth Hendrickson |
| Johanna Rothman's Managing Product Development |
| Brian Marick's Exploration Through Example |
| Esther Derby's Insights You Can Use |
| Laurent Bossavit's Incipient(thoughts) |
| Dale Emery's Conversations with Dale |
| Martin Fowler's Bliki |
| Creating Passionate Users |
Archives
Subscribe
RSS Exploring Solution Spaces XML
2006.Apr.11 Tue
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.