Purple Technology  
Agile, Open-Source Java and XML.

Search WWW Search www.purpletech.com


Words of wisdom from Alex: maxims and advice. Take with as many grains of salt as required.

Java makes it easy to do the right thing.

Java: Write once, debug everywhere, run anywhere.

Read my lips: No new Perl.

Parentheses are free. Use as many as you like. You can always resolve order-of-precendence confusion by adding parentheses.

Copy and paste is more trouble than it's worth. You always feel like you're going to save time by copying code from a different file or function. But from a cognitive perspective: if you have a problem, you just have to solve it. But if you copy-and-paste, not only do you have to solve your problem, but you also have to figure out what the differences are between your old solution and your new solution, and then edit them out.

As a rule of thumb: the third time you find yourself copying the same bit of code, make a new file or function and paste it there instead.

In Java, there are no pointers. Also, in Java, all objects are pointers. Java really has pointers (they're called "references"). What Java doesn't have is pointer arithmetic . And that makes all the difference.

It's cheaper to buy another CPU than to hire another programmer. (See Brooks' law.)

Any problem in computer science can be solved with another layer of indirection. - David Wheeler

McFarland's Corollary to above: one such problem is legible code.

Any resource that is not infinite is a bottleneck.

EJB takes bad programmers and turns them into mediocre programmers. ...which is actually a very good thing!

Maximize Directionality I don't know much about OOAD, but one thing I do know is: maximize directionality; in other words, minimize bidirectionality. If knowledge about another object is represented by an arrow, you want to try as much as possible to make an object (B), when pointed to, not point back to the object that pointed to it (A). If you find you have bidirectional knowledge, you can resolve it in a few ways; to wit:

  1. Take some of the functionality out of B and put it into A;
  2. Make a new object (C) that points to (has knowledge of) both A and B, and then make A and B ignorant of each other;
  3. Make an interface (I) abstracting the stuff about A that B needs to know, and make B refer to I instead of directly to A

The interface is the product If your customer discovers a blocking bug in the interface, or can't find the feature he's looking for, then it doesn't matter that the backend works -- as far as your customer is concerned, the whole thing is totally broken. See the Macintosh Human Interface Guidelines for inspiration.

I have since found a paraphrase of this quote ("The user interface is the program") attributed to Alan Kay. While I remember coming up with it on my own, I'm more than happy to share the credit. :-)

Never use the following words: just, trivial, should, soon.

These are what Gerry Weinberg calls Lullaby Words : words that use their ambiguity to lull the listener into a secure sleep.

For "trivial," use "straightforward."

  • That bug will be trivial to solve.
  • That bug will be straightforward to solve.
  • For "should," use either "must" or "might."

  • The customer should provide the sales data by August 1.
  • The customer might provide the sales data by August 1.
  • For "soon," either pick an exact date, or use "never" (it's more honest to exaggerate than to minimize).

  • I'll call you back soon .
  • I'll never call you back.
  • And never use "just."

  • We'll just need to install Oracle.

  • The model calculates; the view iterates. In other words, isolate the complexities of figuring out *what* to render, and let your GUI concentrate on *how* to render it.

    Premature optimization is the root of all evil. (Donald Knuth) See Introduction to Code Tuning in McConnell's Code Complete "The only thing you can usually be sure of without measuring performance is that you've made your code harder to read."

    Nothing is trivial. Or, everything takes time. (See "lullaby words" above.) Even though a task is easy, it will take time to do. And anything that takes time can be interrupted. And anything that can be interrupted might take a long time to actually, finally finish. (The XP Planning Game can help here -- by measuring how many tasks you get done in a week, you can predict how long it will take to complete a task.)

    This web site and all materials within are Copyright © 1998-2002 Purple Technology, Inc. Permission granted to browse this web site on-line for personal use. If you want to display these materials for any business-related purpose (like using them to teach a Java class), please contact Purple Technology for licensing information. Source code and related assets are covered under the Purple Technology Open License Agreement.

    Page generated Wed May 04 15:15:10 EDT 2016