Eben Hewitt on Java

Transient and Static

This is a quick post about redundancy. I see this a lot in Java classes:

private static final transient Logger LOGGER = Logger.getLogger(My.class);

What's wrong with that code? At first glance, nothing. It will compile and run fine. So let's look at each aspect of this code.

Because the Logger (whatever implementation it is) interacts with the file system, and is not something that is part of the state of an object, it makes sense to mart it transient--we don't want it serialized with the rest of the object. It can't be--Loggers don't implement Serializable.

It makes sense that we would mark our Loggers private, because no one else should use this logger. A Logger should always be defined in its own class. Don't allow a superclass to mark its logger protected and let children use it. You don't always know what children you'll have, or what package they will be in, and depending on your output pattern, this can make your logges statements confusing.

It is smart to mark anything you can final, in order to gain a modest performance improvement. If the JRE can know ahead of time it won't ever reassign a reference, it can ignore certain checks. So that's good.

It makes sense to mark your Logger static, because it can and should be independent of instances of this class. It is not part of the state of any given object. It is something that every object will need to do, and static makes it faster.

So there are no problems here, right?

There is a small Java lesson tucked away here. I would change staements like the one above to this instead:

private static final Logger LOGGER = Logger.getLogger(My.class);

Why? It would seem that this would be problematic in network-based distributed applications, including those using RMI-JRMP EJBs. If Serialization isn't handled properly, all of your Beans could stack up in a single server, never allowing your Container to migrate your EJBs to another node on the cluster, right?

Well that's the right idea, and the code as first given will compile and run. But the lesson is this: static things are not serialized with an object anyway.

So marking a field both "transient" and "static" is redundant.

Object Creation and Super Constructors

Object Creation and Super Constructors

Recently I was writing a little framework for making multi-step wizards in JavaServer Faces with my friend Brian. We have an AbstractWizard class that acts as a default implementation of IWizard.

Any concrete wizard will be a Faces backing bean and extend AbstractWizard and create a set of IWizardStep implementations. The concrete wizard knows about each of its steps, and the user can navigate Previous and Next through the wizard. It is fairly simple.

But the initialization logic is somewhat lengthy and complex, as each step needs to be created right away; EJB delegates need to be set up from the cache, fields need initializing, and so forth.

We wanted to have a cancel button if the user abandons her progress through the wizard. So the IWizard interface defines a reset() method. Reset needs to do all of the same things that the constructor needs to do.

But you can’t reuse a constructor. So we defined an "initializeWizard()" method which implement the Template Method pattern. The superclass sets up the steps’ container in that method, and then we rely on polymorphism to invoke the "initialize()" method. That method is abstract in the superclass.

That is the weird part that doesn’t even sound weird at first: We are using polymorphism to invoke an overriding method on the subclass from the superclass when neither object has been completely constructed yet.

Here is the bottom line: this works great. There are limitations to doing this. The Language Specification advises us to avoid this in general and use care otherwise. It works because we strictly avoid doing anything but initializing values in that method. In particular, we do not read any fields.

That is because we cannot rely on the state of those fields. The reason is stated in section 3.2.1 of Java Language Specification 3^rd ed.

Here is what happens when an object is created:

The 3 Phases of Construction

1. Invoke superclass constructor.
2. Initialize fields using their initializers.
3. Execute the body of the constructor.

1:

Invoke the subclass constructor.

Memory is allocated for all fields, including those inherited from superclass.

Fields are set to default initial values (0 for numerics, null for objects, false for Boolean, ‘\u0000’ for char). Fields do NOT have their decalred values yet.

The subclass constructor now invokes the superclass constructor.

The 3 Phases of Construction are invoked recursively until the constructor for Object is reached, and then stops at it.

If this() is used to invoke another constructor, then Java follows the chain of constructors until an implicit or explicit call is made to a superclass constructor.

2:

Initialize fields using their initializers and any initialization blocks in the order in which they are declared. "References to other members of the current object are permitted, provided they have already been declared".

3:

The actual statements of the constructor body are executed. Control then returns to the constructor that invoked it.

That process repeats until the subclass constructor body has entirely executed.

Example from JLS:

Class MySuperclass {}

Class MySubclass extends MySuperclass {}

Steps that occur:

1. Fields set to default values.
2. MySubclass constructor is invoked.
3. MySuperclass constructor is invoked.
4. Object constructor is invoked.
5. MySuperclass fields are initialized.
6. MySuperclass constructor is executed.
7. MySubclass fields are initialized.
8. MySubclass constructor is executed.

Subclasses can have their methods invoked before superclass constructors are complete. Such methods should NOT read instance fields, as they are likely to be initialized only to their default state—because the subclass object is not yet done being created.

Notes:

If an exception is thrown during construction, no reference to the object will be returned.

It is legal for a superclass to call subclass methods via polymorphism but one should be very careful doing this, as the subclass is not fully formed yet—that is, its fields are not entirely initialized.

The JLS states: "Methods you invoke during the construction phase of an object must be designed with these factors in mind. Your constructors should avoid invoking overridable methods (methods that are not final, static, or private). If you do, invoke such methods, clearly list them in your documentation and alert anyone wanting to override them of their potential misuse."

So while the JLS says to avoid it, it makes more sense to me in this case than it would to incur the maintenance issue of copying and pasting code for every wizard our application defines.

Finally, we 1) thoroughly documented what we are doing and refer readers to that section of the JLS and 2) we use it for the express purpose of initialization and do not rely on the values of any fields--we merely set them.

A Lesson In Tier Violation

I encountered a very sort of weird thing that I found little
assistance for on the Web, so I thought I'd write out what
I discovered in case anyone else has a similar issue.

This is a lesson in the pain of violating tiers in your design.

This is a strange tale of an IBM driver and how an EJB container
works and how apparently misleading or at least apparently unrelated
issues end up making sense and being related.

I have a Session EJB running on WebLogic 9 which implements
the TimedObject interface available since EJB 2.1. The purpose
of the bean is to execute a SQL statement every morning at 4 am.
The database against which the SQL statements are run is DB2
on an IBM iSeries. So I'm using IBM's jt400.jar driver to do this.
I had set up JDBC DataSource in the WebLogic console, and it was
working great for a couple of weeks.

One night before leaving work, I quickly added some boilerplate SQL Statements
to my Timer bean, which were placeholders for when I got the real files in the
promoted library later on. I wanted to be done with the use case, and move on,
but I didn't have the real files yet, so I put in this placeholder.

Suddenly my entire WebLogic server would not start.

This was what I added to my DAO:

private static final String GET_PRODCODES = "SELECT PRODCODE FROM POPRODLB.PPPRDPF";

What about writing a standard SQL Statement like that would cause
the entire server not to start?

WebLogic says that the reason it would not start is because I was suddenly
throwing a HeadlessException. This is a very rare exception that was added
to Java 1.4. It is meant to be thrown when you try to make a connection to some
user input device, such as a mouse or keyboard or display, but the system has no
user input devices available or graphic libraries to route the message through.

I could not understand how my simple, apparently innocent statement could
bring down my entire server. Here's the weird answer:

I knew it had to be something in the SQL statement, since that was the only
thing that I had touched. Now a lot of people use this box, so it was possible
that there was some inadvertant side effect from some other app, but that seemed
like the sort of lame thing programmers tell themselves in the hopes of not
being responsible for the issue.

But 1) There's nothing wrong with that SQL statement and so why would there
be an exception at all and 2) how would the container know because I am not
executing this bean right now--it's not 4 in the morning. I am just trying to
start the server.

When you start WebLogic 9.0, it loads your EJBs and does a trial execution of
your all of your EJBs methods so that it can guarantee that it is at least
possible to run them all properly. It was not able to run some method properly,
so it was refusing to start the server.

What was I doing to cause a HeadlessException though? That's what the stack trace
said. Not knowing what the issue was, but isolating what I had changed (which must
then be the cause of the problem), I commented out my SQL call. My server started.

I am executing a number of queries, using the same DAO, and this is pretty standard
stuff. So I looked at my SQL statement again. The "PPPRDPF" file referenced in the
query was named wrong. The real name is "PPPRODPF". I didn't pay much attention
to the name because I knew that the files would be renamed and would move anyway
for the new version of the application I was writing.

But WebLogic not only ensures it can invoke the methods, it executes the methods
without committing. which includes running the SQL statements.

So that is a reason why I love WebLogic. But it also means that my improperly named
table, which should cause a SQL exception to be thrown, is throwing HeadlessException.
Now it is true that I am executing the statement via this DataSource running on a
Linux box with RedHat Enterprise and no mouse or keyboard or display connected to it,
and no GUI libraries.

It had to be the driver. So I asked my friend Kevin about it, and he said that the
driver might be throwing that exception; he recalled seeing that before.

It turns out that the way IBM wrote the jt400 driver, it pops up a dialog box when
a SQLException is generated, indicating the getMessage() text.

So I changed the name from "PPPRDPF" to "PPPRODPF" and everything worked perfectly and
my server started.

There are two problems here:

1) With release of Java 1.4, we gained the ability to chain exceptions. This is a good
practice, and one should always do it. IBM was not chaining their exceptions. There
was no indication that, at root, the problem was a SQLException. The HeadlessException
was the only thing on the stack.

So the exception lesson is: always chain your exceptions so that the user can later
unravel the nested exceptions and find the root of the problem, and not chase their
tail on some epiphenomenal, unrelated matters.

2) Don't violate tier boundaries. In an enterprise Web app, there is a right way to design
your tiers. Using JavaServer Faces and EJBs, it probably looks like this:

Tier 1: Presentation (JSPs) and View Helpers (JSF Backing Beans).

Do not put any logic in your JSF backing beans (or Struts actions or equivalent) that is
not merely related to
1) translating your models into JSF-required models. For example, you need code like this:

final DataModel dm = new ListDataModel(userDelegate.findEditableUsers(getCurrentUser()));

to turn your basic models into JSF-specific things like SelectItems or DataModels, so they
can be displayed.

or

2) Managing the user view.

For example, your Backing Bean should have methods like this:

    @Override
    public boolean isRenderEditButton(){
     return !isUserInRole(SuperUser);
    }

to determine whether or not to show some panel grid, etc.

That should be all you do in a backing bean or Struts action. Business logic other
than that required to gather the view doesn't belong here.

Tier 2: Delegates
The Business Delegate pattern indicates that you do two things here:
1) Use an implementation of the ServiceLocator pattern to find your services (EJBs or
Web Services or what have you) and
2) Wrap any exceptions, like RemoteException, that they might throw into more
general application exceptions.

This is all standard stuff. But you don't do anything else in the tiers. You're aiming
for high-cohesion. That is, have a class or type of class be responsible for just one
job. Notice that the apparent two jobs of Business Delegate are really one job: encapsulate
how the service tier is implemented.

No business logic belongs here. No presentation knowledge whatsoever should be present here.

Tier 3: Service
This is your implementation of business logic, often EJBs or POJOs or WebServices or whatever.
Just hide it. Do your work there. Use a rules engine like drools or the Interpreter pattern
or the Visitor pattern or whatever you like to apply business rules here.

I like Visitor for this, but I recognize that I am in the minority perhaps. Visitor is nice
because you can represent a one-to-one translation between a business rule written by an
analyst and a single visitor class. But that's for another topic.

Your EJBs should work identically if your client is a Faces app or a Struts app or a Swing app.

Tier 4: Data Access
These are DAOs that know what database they are talking to. Use a DataSource.

DAO methods look like this:

public List<Manufacturer> getManufacturers() throws PersistenceException { ... }

Notice two things:

1) We're returning a list of models.
2) We're wrapping the SQLExceptions that our RDBMS throws with a custom exception called
PersistenceException, in order to hide the implementation. That is, to hide the fact that
it is an RDBMS that we are using to persist data.

If you change your database to a flat file, you would have to change code in Tier 3 (your EJBs).
That would be bad. If you wrap your exceptions, (chain them), then you haven't violated
the tier boundary, and your code is fine. If your new flat file access code starts throwing
FileNotFoundException, you're still wrapping those with PersistenceExceptions, so your
clients don't change at all.

You still have knowledge of the root cause of the issue, because you nest those exceptions
this way:

         } catch (SQLException sqle) {
             LOGGER.error(sqle);
             throw new PersistenceException(sqle);
         } finally {
             DBConnection.close(conn);
         }
         return mfrs;

So you haven't lost the original problem, but you haven't violated tiers either.

Tier 5: Persistence
The RDBMS or XML file or fixed length field text file or serialization to the file system
or whatever stores your data.

With the sole exception of Tier 4 (DAO), there is not a reason in the world that any other tier
or the model or any other thing in the whole world of your app should know how your data is stored.

There are a lot of other patterns that come into play at the various stages here. But this
is the basic structure.

Create your models and transfer objects without regard to any of these tiers. They must
be completely independent of any knowledge of how these tiers are implemented.

So we see quickly that a given tier can
1) know about the tier immediately below it, but
2) it must not know about any tiers below that tier, and
3) It must not know anything about tiers above it.
Period. Ever.

This is so important.

A model must know have code that mentions Struts in it. Period.

An EJB must not know that it is talking to a DAO that is talking to Oracle 9i. Ever.

If it does, you're doing it wrong and you or your users will suffer.

You can pay now, or you can pay later. It's really just easier to pop up a dialog when
the problem happens. That's why you'd program that way. But nothing's free, and eventually
you will pay. And in programming as in life, when you pay on the installment plan, there's
always interest, and it's always more expensive.

Don't write code like this:

public Product(boolean webProduct) { ... }

to indicate whether your model is a product that will be shown on the web or not. These are
not the only two choices (web or not web). What if it's web or swing or a C++ app at the
other end of a web service in which case its XML which means you do't know if it's a "web product"
or not or in a midlet on a cell phone. Boolean doesn't cover all of
those choices. But a model shouldn't know about any of the implementations of any of the tiers
in which it participates.

If you code that way, why not start writing Struts-specific stuff in your DAOs? What if
you change to JavaServer Faces? Still digging in your heels after it's an official
requirement for implementing the Java EE 5 spec?

I see examples of this surprisingly often. I feel weird writing this even because these
things have been said so many times, by people smarter than myself. But I am writing it
because it hasn't seemed to soak in quite yet.

If you violate these tier boundaries, you are guaranteed to have problems. It might take
six months or a year for them to come up, but they will come up.

IBM for some reason assumed that its driver would always be running on a box with a load
of GUI controls. That assumption is totally unfounded and caused me to go on a wild goose
chase that wasted a day for me.

To have a database driver pop up a GUI dialog box is a tier boundary violation, and is
bad writing.

Be strict with yourself about this sort of thing. It sounds a little far-fetched maybe when starting a
project that different tiers might change. But they really are likely to. Systems get interconnected
by business people in ways that programmers never imagine. Companies get bought. It is very
important not to paint yourself into a corner.

When you want to slip business logic into your delegate because it's quick and easy, you've got
to resist that urge.

Using XDoclet with JDK 5

If you are using XDoclet to generate EJBs and have noticed that it chokes if dependent objects use any features of JDK 5 such as generics or static imports, there is a workaround until XDoclet 2 comes out.

Download the JAR from http://prdownloads.sourceforge.net/xdoclet/xjavadoc-1.5-snapshot050611.jar?download and replace the xjavadoc-1.1.jar with that one on your Ant path.

Works great.

You Wouldn't Talk That Way

Work with me for a second. When a colleague greets you in the hallway and asks "How are you?" what do you say? I bet you don’t reply, "I am well." Let’s examine that. We modify verbs with adverbs, and "well", in this context anyway, is an adverb. To be fussy about it, we might say "I am well." But we don’t say that. We say, "Good. I am doing good."

Likewise, we are taught in school that it is bad form to end a sentence with a preposition. Prepositions are words that, if elementary school textbooks are to be believed, would appear to describe a squirrel’s ongoing but only semi-intimate relation with a tree. As in, "The squirrel ran at the tree. The squirrel ran up the tree. The squirrel ran around the tree." And so forth. What we are never allowed to say is "Where’s the squirrel at?" It’s a preposition-ending-with-one-sentence. And language snobs purse their lips and cough quietly when you do that. The keepers of English hate that sort of thing. It’s not that you can’t be understood you when you end your sentences thusly, it’s just irritating to no end, apparently, simply because it isn’t proper and isn’t absolutely correct. We should not be so idle. We should read Strunk and White, not merely refer to it.

The nastiness of ending sentences that have no object with prepositions is best described in one of my favorite jokes. It goes like this:

A Harvard student finds himself unluckily on the Yale campus one brisk Fall day in order to do research. He asks one of the local students, "Where’s the library at?" The student responds with caustic condescension: "At Yale, we don’t end our sentences in prepositions." The Harvard student curls for a moment, but quickly replies "Oh, I’m so sorry. Let me rephrase: Where’s the library at, jackass?"

This is a very funny joke. But what does that have to do with programming? As it turns out, a lot.

There is theoretical purity in the world. It is a Good Thing. It is pretty and elegant and makes the day delightful. Life is, uh, gruesome at times. If I didn’t have the gorgeous and pure systems of the world to remember now and again—Freud’s Civilization, Spinoza’s Ethics, set theory, and programming languages—to remind me that there are theoretically pure things, that would appear to all work together like some massive and wonderful clock, I fear I would become quite sad indeed.

However, that is a description of a sort of general and embellished psychological state, and not a description of a programmer working.

If we spoke perfect English, the English that we know is actually correct—read "theoretically pure"—we would sound like jackasses. For we would indeed be jackasses. We would say, "On which line shall we initialize the recursion?" Our friends and colleagues would think "what a jackass,"—and rightly so, for, indeed, a jackass we would be.

We don’t talk that way, even though we know better. You might respond that chit chat in the hallway is a less formal endeavor than programming. By the same token, there are more or less formal programs to write. I’m just saying, some little Python script to traverse a directory tree, don’t get all weird on me.

I like the analogy. I think it’s the same thing. I think: know the rules; be theoretically pure in your head. But be context-specific. Know who is writing the check. When you think it’s time to write your own personal enormous MVC framework that uses 27 XML config files, really ask yourself if that’s what the world needs, and if that’s what the check-writer thinks he’s writing the checks for. If you’re not sure, ask.

There are formal programming projects that are large scale. Don’t use entity beans for the CEO to post a picture of his dog because some book told you that that’s the component that represents entities based on identity. Give me a break.

Know the patterns. Use them. Are you quite sure that your custom Faces calendar UIComponent needs an Audit Interceptor and an Obfuscated Transfer Object?

I guess I’m trying to say that one size doesn’t fit all.

When you receive the Nobel Peace Prize, and somebody asks you how you’re doing, go ahead and say, "Quite well, thank you." No one will think you’re a grammar pervert. No one will think you’re a snob. They will all think, "what a gracious and lovely person." And rightly so.

Using old JAXP XPathAPI class in Java 5

You might have an application that uses org.apache XPath API that you implemented with Java 1.4 using Xalan. If you do, you might find that your code compiles and runs, but that your XPath queries return null.

This is easily fixed: change your import statement.

org.apache.somePackage --> com.sun.org.apache.SomePackage.internal

Check out this document for more info on what's different in Java 1.4 --> Java 5 with regard to JAXP.

http://java.sun.com/j2se/1.5.0/docs/guide/xml/jaxp/JAXP-Compatibility_150.html

Note that you can still use your Node and NodeList objects, as the constants in the new Java 5 XPath library will map directly to them. But this whole deal is just if you do not have the time or inclination to rewrite your XML parsing using the javax.xml libraries. If you do have the time, it's probably a good idea, since they run faster.

Models should be pretty, dumb, and self-absorbed

I like software to look like the real world. That’s because in my experience

1) that's when it works best.
2) that’s when it is what users actually want and need.

So today I’ll talk about a sort of corollary of this. Make your software model objects like models in the real world: pretty, and dumb, and self-absorbed.

Why self-absorbed? If you need your model to do anything that might be about anything but itself, don't ask it to do that. You’ll reduce your ability to reuse it later. Anyway, there are patterns for this sort of thing. Decorator maybe. Template Method maybe. Composite. Adapter. Let your models stare in the mirror all day long and think about nothing but themselves. Use patterns when you need them to do something in your app.

If there are things that you know your model will always need to do (diet(), and pose(), perhaps), then those functions can be written into a common object model that you can use over and over again. But probably they should only be written in if what they do is actually self-contained enough to really persist over time, and over many applications, and everyone on the team is pretty clear about it.

Take Martin Fowler’s Value Object Money, for instance. A Value Object is an object for which equality is not based on identity. He outlines this in his excellent book Patterns of Enterprise Application Architecture. Money only does stuff that is 1) True and consistent and that will persist for all time and 2) Is 100% confined to talking about itself. You can add, subtract, divide, multiply, and sort it. That’s it. They’re just talking about themselves.

How dumb? It might be surprising how little your model objects can actually do. If you think that your models are supposed to implement Comparator in order to be more behavioral or complete, you're going to run into problems later when you need to compare from another view.

The solution to that last point is to make a “comparators” package and put them all in there. Keep them separate from the model objects themselves. The act of comparing is an application-specific action. It isn't something that models would know how to do very well for themselves.

Money will likely behave very differently in a stock quote app than it does in a betting app than it does in a mint app. Don't bake things in that don't belong, especially when building out a common object model that you expect to be reused in a set of internal applications. It's okay if models are dumb.

Finally, I also said that models should be pretty. That means that you follow Sun's coding conventions and document your stuff. Don't get all weird about it. If your code doesn’t make sense and your members aren’t well-named, there’s nothing about where you put the plus sign when concatenating strings that is going to fix that. Modern IDEs mean that we don't have to worry about formatting much, though. It is easy to create a formatter in Eclipse, share it with the whole team, and then just ctrl + shift + f every once in a while (before you check it in).

Explicitly set serialVersionUID

I always specify an explicit serialVersionUID for a Serializable classes, like this:

public class Something implements Serializable {
     ANY-ACCESS-MODIFIER static final long serialVersionUID = 42L;
     //...
}

While any access modifier is allowed, we always use "private", because
serialVersionUID is useless as an inherited member,
and must be re-specified in subclasses.

It's a good practice for developers to follow, and this post is meant to tell you why.

Frequently Java programmers don't do this at all, and instead let the
serialization runtime insert a serialVersionUID for them.

While reflection is used to generate this id, the idea that explicitly
specifying yourself it is a performance boost is widely disputed. See this article on performance:

http://www.javaworld.com/javaworld/javaqa/2003-06/02-qa-0627-mythser.html

Note, however, that performance is not the reason Sun says to do this:

The really authotitative source of course, is the JavaDoc for Serializable:

http://java.sun.com/j2se/1.5.0/docs/api/java/io/Serializable.html

And so here's the relevant text from the JavaDoc (bold emphasis mine):

If a serializable class does not explicitly declare a serialVersionUID,
then the serialization runtime will calculate a default serialVersionUID
value for that class based on various aspects of the class, as described in
the Java(TM) Object Serialization Specification. However, it is strongly
recommended that all serializable classes explicitly declare
serialVersionUID values, since the default serialVersionUID computation is
highly sensitive to class details that may vary depending on compiler
implementations, and can thus result in unexpected InvalidClassExceptions
during deserialization. Therefore, to guarantee a consistent
serialVersionUID value across different java compiler implementations, a
serializable class must declare an explicit serialVersionUID value. It is
also strongly advised that explicit serialVersionUID declarations use the
private modifier where possible, since such declarations apply only to the
immediately declaring class--serialVersionUID fields are not useful as
inherited members.

Here is an article that says more about it, from the O'Reilly Java RMI book.

http://www.oreilly.com/catalog/javarmi/chapter/ch10.html
(search for "serialVersionUID" -- it's about 3/4 of the way down the page)

This perhaps isn't earth-shattering, but it's a good practice to follow. Just make sure to keep them up to date.

If you use Eclipse 3.2, it will complain if you have a serializable class that does not explicity have this field. If you click on the warning and choose "Add Generated SerialVersionUID", it will use the serialver tool under the hood to create something like this:

private static final long serialVersionUID = -4779071564826573237L;

Writing online

I've noticed this: one must be very carefully in interpreting emails, and indeed the written word on the Internet.

Emails have no context for the voice. They are not accompanied by gesture, vocal pattern, or facial expression. Much has been written about this and I won't rehash it here. However, there is one thing that can serve as a guide when trying to fathom the general feeling or intent behind an email you get from someone you don't know too well.

People over thirty think that an email message is an quicker, sometimes less formal version of a written letter.

People under thirty think that email is a slower, and unfortunately more formal version of an Instant Message.

Not that we always know the age of our Internet interlocutors. But this does tell us something about how to communicate with each other. I experimented a little with the kind of writing that might feel like the internet in my recent book Java Garage. Some people loved it, and some people hated it. It seemed from my vantage that those who were more inclined to like that book were younger, and it was young people (college age) who were the target audience.

But it was trashed by older, dare I say more vocal, readers, who I think equated its very conscious style with a sort of degeneration of culture. I have a Masters degree with an emphasis in literary theory. I know some things about writing. Like sentence fragments. When I end a sentence with a preposition, I know where it's at. Writing with gerunds and participles comes easily to me. When I split infinitives, uh, it's on purpose; I want to boldly write as no man has written before.

But that book is over, so I'm not selling anything here. I'm trying to make a point about communication, specifically in the tech world where it is crucially important to talk in a very precise manner. This is true of any engineering field (I refer readers to the scene in Spinal Tap where Nigel has the contractor make a 12" Stonehenge monolith for a concert prop).

No one has criticized the Java content of the book. I haven't seen a better explanation of abstract classes anywhere. But they hate the style.

There is an old Ray Bradbury short story called "A Sound of Thunder" that characterizes the total degredation of culture in a series of signs on shop windows and newspapers that are written with broken English--a weird, prescient mix between Prince lyrics and a typical 13 year old's AIM session.

This is perhaps a characterization with which the French Ministry of Culture could agree, as they carefully interrogate words and phrases to be admitted to the language, regardless of the fact that French teenagers use the term "blue jeans" to refer to "blue jeans". This is no different than a manager in America giving a programmer "carte blanche".

I wonder if a very meaningful case can actually be made, that the Internet is helping destroy culture by destroying language. While something in me revolts when I see a phrase such as "I want 2 b a programmer at yr company", I think it is not the language against which I revolt, but the fear that the means of expression is the only one available to the writer. When I read the inner sleeve of Purple Rain as a 13 year old, it didn't occur to me that Prince was anything short of a master of expression--something I still think. He has many means of expression available to him, and writes in what used to be an innovative way.

I am in love with language. If language can be torn down, start tearing. Break its bones. Destroy the English language, which itself, we might do well to recall, is a cacophonous destruction of German, French, Latin, and many other langauges. Have you ever read Chaucer? If you have, I bet money your reaction wasn't "Oh, Eliza, how far we have sunk into the despair of our current English language. How sad a state that we don't still write Middle English." No one thinks that because it would be idiotic. In part, it would mean that one must suggest that Shakespeare had only a paltry language available to him. In many ways, that's true. He was larger than the English language could contain. Shakespeare single-handedly contributed more than 1200 words to our language.

What would the ministry of culture say?

Getting Better Requirements from Customers

As we know, software projects fail at alarming rates--typically somewhere around
80%.  There are many reasons for this. One reason is that the programmers get the wrong
requirements. Changing requirements and scope creep are separate issues that need addressing
on their own, and I'm not going to talk about that right now. There are more things afoot
with this Getting the Wrong Requirements business. Often, the programmer or analyst
interviews with customers are simply ineffective. The interviews don't get to the bottom of
the issue, or we come away with an incomplete understanding of what the customer wants.

In Extreme Programming, there is the concept of the User Story, which is intended
to capture a use case in its simplest form, and leave details open to continuing
conversations between the customer and the programmer/analyst. The idea is that
requirements change, and because of that, our documentation gets out of date quickly,
and you have a lot of people trying to maintain documentation that generally isn't
trusted anyway (because it's known to often be out of date or incomplete), and that
such maintenance is, like, a waste of time.

I can see that. I agree with that, even, that it's good to focus on the software product, communicate through code, talk a lot with the customer, and not on chasing around these massive documentation tomes.

However. There are many problems here.

The first of which is that the "customer" doesn't exist.

The Customer Doesn't Exist

What we talk about when we talk about customers in software development is often this
necessarily idealized concept of the customer. As if there is one person who can answer all
of the questions. Who knows enough, is available enough, is approachable enough, is articulate
enough. Often the customer consists of more than one person. A committee of executives, perhaps.
You may need all of a few of them to get a decision or clarification.

It is therefore a good idea to get something more out of them when you have the opportunity
than a User Story card with some cryptic phrase like "[Make ecommerce here]" scribbled on it.

But even when we record enough about what the customer states, adjusting as requirements change, we still don't get it right. Why not?

I have observed that frequently customers will give you the Solution, but not the Problem.

This is a Bad Thing. It is your job to write great software, and the customer's job is to help you
do it. They help you do it when they give you the Problem, and you determine the right Solution.
You are a professional. That is your job. This kind of thing makes me nuts.

I don't tell the dentist where to drill, or if he really should give me a root canal or not. I do
as I'm told because I don't want my teeth rotting out of my head and on such matter he knows bloody
well better than I do.

Yet in IT we let customers railroad us all the time. The same customers who wouldn't dream of telling their dentists that the porcelain bridge is actually inappropriate in this case, and shouldn't he
really use this new polymer she heard about from her stock broker.

Notice in your customer's conversation whether they are giving you the Solution instead of the Problem. And don't allow it.

Everyone will pay later if you allow it. You'll pay, the customer will pay, the customer's customers will pay.  It's part of your job as a developer/analyst/architect to notice this, put a stop to it, and _force_ the customer to clear her head and forget what all about what her 14 Year Old
Nephew Who Is Really Not Too Bad At Front Page And Had Some Good Ideas Regarding This told her she could do.

This can be surprisingly difficult. People don't like bad news. They don't like to pay for something they didn't choose. They might not trust you entirely, and think you just want to play with that new toy or get it on your resume.

But that's the name of the meeting in your little digital invitation after all, "Requirements Gathering". It doesn't say "Solution Telling by Customer Meeting". But in the current culture, Front Page is the New Word. Whereas in the 80's only a complete dumbass Luddite geezer didn't know how to use Word Star, and secretaries who took dictation went the way of all things, for the last few years we've been smack in the middle of in the age when only complete dumbass Luddite geezers don't make their own web pages with copied and pasted applets. They know all about it now. They just program their VPN with HTML and send it up to the HTTP and 6 phone calls later to a help desk or that 14 year old nephew and they're good to go. What that means for you 8 times out of 10 in that any given customer now feels sufficiently on top of things that they can tell you what it is they need. I just need a floating applet in the shape of a cube that I can rotate and get my files by clicking on them as the cube rotates around. I saw it at my wife's work, and that's just what I need. 8 times out of 10, that's not at all what they need.

Your Customer is Not Your Customer

Here's another strategy. Pretend, as you develop software and work in requirements meetings, that your customer is not your customer. It turns out that this is a very easy thing to do, because it is true.

Your customer's customers are your customers.

If your customer's customers win, your customer wins.

If your customer's customers win, you win.

If you're writing an ecommerce application, take care of the things that you know people who will shop at that site will need. They'll need SSL. They'll need encryption of stored data. Your customer may not mention this. If you know that your customer is leaving out things your customer's customer will need, get it addressed.

If your customer willingly and knowingly doesn't care about certain important things that your customer's customer cares about, consider stepping away from the project. It's Teenage Suicide (don't do it). Just because Sally customer doesn't want to pay for SSL every year and wants to store credit cards in plain text because it's six hours less you have to get paid to encrypt them, it's not okay to just agree. You're killing your customer's customer when you agree to work you know is a bad idea.

Customers all have Windows ME, and iPod Shuffle, and some old $30 Lexmark printer in their garage, and this entitles them to judge whether or not SSL is a requirement. It's idiotic. Yet we in IT put up with it, because it's easier to do it wrong and then gripe about it to our sweethearts who get to find out what heros we really are because we would never have been so stupid to use an Active X control when Flash can export XML.

If you're the guy who hangs around the garage telling the mechanic what to do, how about you stay home. If you can fix it yourself so great, then stay home and fix it yourself, and leave room on the mechanic's schedule for nimrods like me who only in the last 6 months learned the difference between a tire and a wheel. I need the slot, dammit.

You can recognize meetings where you're going to get the Solution instead of the problem in this way: as you are in the meeting talking to the customer, you find yourself nodding your head, saying little, things vaguely make sense--but the details are sketchy, and when you get out of the meeting you have no idea what the customer actually wants, why they want that, or how to build it.

You can recognize this kind of meeting if the customer is sketching forms for you.

If they are saying anything at all about checkboxes or applets or CSS or XML.

Requirements gathering meetings are not implementation meetings. Just forbid the use of implementation-specific terms unless it's part of the domain, or an absolute. Now one can't be rude, but you have to be disciplined enough to just strike these things from the record, as it were, in the Perry Mason courtroom of your mind.

So how do you maintain the discipline in these meetings, which can be deceptively difficult? It requires a paradigm shift.

In 1649, Richard Lovelace wrote a poem called "To Lucasta, on Going to the Wars". Here it is:

Tell me not, Sweet, I am unkind
That from the nunnery
Of thy chaste breast and quiet mind,
To war and arms I fly.

True, a new mistress now I chase,
The first foe in the field;
And with a stronger faith embrace
A sword, a horse, a shield.

Yet this inconstancy is such
As you too shall adore;
I could not love thee, dear, so much,
Loved I not honor more.

So what does Lovelace teach us about customers on software projects? That you must honor the customer by fixing their problem. Their real problem. Their real problem is not that they need hand holding. Or chocolates at meetings. Or someone who should know better to simply nod their heads in agreement with every utterance. We must not be afraid of our customer. Even if it's the boss. Sometimes if our customer is the CEO of our company, this can be difficult. I understand. It's our job.

They knew in New Orleans that the levees would break. Engineers told them. They made it clear. Years in advance. They could have fixed it. They were told how. The city and the state didn't want to spend the money. They feds didn't want to spend the money.

This frequently happens in IT. It happens every day. I understand. That doesn't mean we get to float through customer meetings griping under our breath that it'll never change around here.

No One's Customer

You cannot solve the customer's problem without solving at least a couple of IT's problems along the way. Frequently, companies are divided up for accounting purposes such that HR would have to pay IT for a project from their own budget. Sometimes this practice is so rampant that the departments are even divided into their own companies. That's fine. I'm not an accountant. But sometimes when this is the situation, we frequently find our IT infrastructure in shambles after years of doing projects for other departments. That's because everyone is our customer, but we're no one's customer. Your company may not like to pay for IT keeping up its infrastructure. They'll deploy Windows XP to 20000 desktops with no discernible improvements over Windows 2000 with the exception of the possibly useful feature of the built in wireless driver manager. But we can't upgrade the SAN. We can't afford another Admin. If you're in such a company, I can't help you. I don't know the cure. If you know the cure, let me know. Because we can't control that. It's not our money.

But the requirements gathering meetings, _are_ our meetings. Our name is on it. It's our shot to help call.

If your customer doesn't want to talk about security, because security is expensive, isn't sexy, and isn't even a _feature_ in the customer's mind, you must force the conversation.

You cannot love your customer so much, love you not IT more.

The customer doesn't want to pay Microsoft for 5000 seats in Active Directory. No one wants to pay Microsoft 5 cents for anything ever again. It somehow just doesn't seem right. But if they want indentity management, there's just no good way around it.

You know what the problems are going to be. The customer probably doesn't. You know that any website worth writing will be hammered non-stop with DoS attacks. Customers don't care. Because security is not the problem they asked you to solve.

In fact, as my friend Barney says, "security is never a problem. Until it's a problem." Then _you're_ the jerk who didn't impress upon me the dire need for SSL and data encryption--I _told you_ that security was important.

Have the conversation now. I just use security here for simplicity. The issue may not be security in your app. Maybe they'll pay for iris scanners till the cows come home. It's something else maybe. But I bet it's there.

I've actually found that there is little predictability in what customers will or will not pay for from project to project. Even the same customer. But I think I know why this is. I've found that this is generally because the customer wants what his golf partner (read Bourgeois rival) just got His IT Guy to do. Hm, you know I overheard in the clubhouse that the CIO of Dial is putting in RFIDs. I better put in some RFIDs too. Let's find something to put them in.

This all sounds so obvious. We all know this. But I see it day after day.

Do not agree to things you know you shouldn't agree to. That includes deadlines, cheesy specs, incoherent requirements. Later they're going to forget all about the fact that you "really tried" to get them to buy the firewall between the web server and the app server. You must make it clear: If you don't buy the firewall, your app will fail. It may take 6 months or a year, but it will fail.

And don't be that guy, the guy that lets the company shoot itself in the foot with your name. If it means you have to walk away, walk away. How many failed projects does it take before the customer decides that you're the common thread in their continual project failures? Two, max? Probably one.

I suppose when the fingers start pointing, and they eventually point at you, your can point at your analyst and your analyst can point back at the customer. And the world will keep turning. But it's not required that we're so passive. They want to know. They might fuss a lot, and really make it seem like they don't want to know. And once they know, they may still not want to pay for it. But then, at the least, we've done an honest day's work.

The onus is on us to get better requirements.

Painter Sergio Roggerone

This painter, Sergio Roggerone, is fantastic: http://www.roggerone.net

Contract by Comment

When you write a class, you are not simply writing a class. You are designing an API for clients of your class. Perhaps this sounds obvious. And when you design an API, it is important to balance power with flexibility, convenience with control. Your interface is your contract.

I saw the following code the other day:

/**...
NOTE: For sale items, the productName MUST end with $S$
*/
public String someMethod(String productName) { ... }

What’s the matter here?

The author of this class is trying to enforce his interface in an extra-programmatic way. He wants us to please not pass anything that doesn’t end with an $S$. But he does not forcibly keep us from so doing.

Note that we are not told what fate befalls those poor saps whose productNames do not end with $S$. The author of this method is Asking "Please honor this programmatic "contract", despite the fact that it’s totally fake, because if you don’t honor it the class will break or, worse, fail silently, or even worse, appear to act correctly while it just silently fails".

This is what I call contract by comment, which is no contract at all. Everyone should know what a phenomenally bad idea this is. In fact, it rather seems that we've heard a butt load of times that we aren't supposed to do this sort of thing. Ever. So what's the real issue here?

The lesson is this: in programming, as in life, and contrary to our social intuition, it is actually more generous to be hardcore. Easygoing people are approachable. They happily give you little bite-size Abba Zabbas from the big plastic sacks they keep hidden in their cubes. Lots of them. They are nice people.

More so, it certainly appears that these easygoing, chirpy folks are "nicer" than the pencil-bending guys at the Monday meeting who are always harping on details, beating the dead horse, foregoing chit-chat about your racquetball club, and not shooting the breeze about how loaded they got in Vegas this weekend.

The water cooler guys seem nicer, if even in a bitchy way. It would appear in fact that we are supposed to become water cooler guys. That the company wants us to gravitate toward the middle, where we loosen our belts after an $8 lunch pasta from Nick’s and complain in a vaguely pained, vaguely self-deprecating, vaguely resentful whine for an extra 15 minutes about how the boss won’t get us tools. Even though they’re 3 million ahead of this quarter last year. The bastards. Ha ha ha. Isn’t it true. Aren’t we collegial.

Guys don’t seem nice who have their heads in their screens all the time. They’re always ranting about "standards". They hate mistakes. They don’t suffer fools gladly. They will argue with you about the implementation because they give a damn about the implementation. I submit that it is these programmers who turn out in the end to be nice. Because it is work. It is your job. It is not a party. It is fun, if you’re doing it right, but given the choice, many of us would be somewhere else any given hour of the work day.

It’s not nice to be nice. It’s nice to be hardcore. Because when you’re hardcore, you’re clear. People know what they are supposed to do. They know how to do it, or know they better find out how.

I don’t know about you, but I don’t like to get a phone call at midnight that I need to come in and fix some broken production app. The hardcore guy’s app doesn’t break, and so he doesn’t get that phone call, or cause others to get those phone calls. I appreciate that. I think it’s nice. Because the attention to detail is there, and because things are dotted and crossed, and because he has been very strict about following the rules and very strict about what he’ll allow and disallow through the firewall, within the cluster, into the method.

In my book, that is the nice guy, because he doesn’t ruin my life. if I wanted to shoot the breeze with somebody, it wouldn’t be Chuck the Analyst down the cube farm who is super nice and didn’t want to hurt the customer’s feelings so they didn’t ask for clarification so we wrote the wrong thing. I don’t think that’s nice to me as the programmer, and it isn’t nice to the customer who’s paying for something they don’t want. If I had to shoot the breeze with someone, it ain’t Chuck. It’s Alison. So if the story here is that we’re going to shoot the breeze with Chatty Kathy from HR, then I’ll just go home. That’s just not a reward for me: I want my stuff to work. And I depend on her. Be hardcore and make your stuff work. People will appreciate your generosity in so doing. If you’re concerned about what others think.

If you’re not so concerned, then ask yourself some pretty tough questions about your API. Make it tough. Make it flexible where it needs to be and convenient where it needs to be, and don’t be mean to your clients by silently failing if they don’t do what you ask.

Disneyland doesn’t ask me nicely to put my seatbelt on, shoot me 1200 feet into the air and hope I don’t fall out. They clamp a big huge steel bar down across me and lock it in place.

Be strict in meetings. Get the work done. Ask the tough questions. It’s nicer.

Be strict in your methods about what params you'll accept, and actually disallow something that's unacceptable. Be a dictator about your upper and lower bounds on a class parameter. Don't hope you get a good deal. Don’t pray that your client’s param ends with $S$. Make sure it does. And if it doesn’t, throw an appropriate exception. If it makes sense, give them a delimited set to choose from that only includes things that end in $S$.

Perhaps an obvious reason that this sort of thing happens, even when we all know we're not supposed to do it, is that it's a lot more work to do things right. In my experience, you pay now or you pay later, and it's always more expensive to pay later. It's more work, and more expense, and more angry users, to fix an app in production. (Something else all programming managers know).

Don’t make a contract by comment. Enforce it programmatically.

Google Hires Vint Cerf

http://news.bbc.co.uk/go/em/fr/-/1/hi/technology/4228910.stm 

Advantages of Pair Programming

There are a number of advantages to pair programming. But you have
to do it right. It's fairly easy, it turns out, to sit two guys
at one desk and suddenly you're Agile.

As I really like Pair Programming (dare I say "PP"?), and practice it
daily, I have found myself defending it, so I thought I would sort of
clarify my thoughts.

I understand from my friends in Cobol land that Kent Beck did not
invent the notion that two heads are better than one. Indeed. It is
clear that in the course of human events that two people have, on more
han one occasion, sat puzzling together at the same problem. Pair
Programming is a term because it represents a real distinction, a distinction
sharper than this; that is, there are ways to do it right and there are
pitfalls. Let's take a look at how to make the most of this nice little
programming construct from XP, and what it really means.

Collective Ownership
Collective ownership protects the company's investment. Again, this is
the idea of the Truck Factor: how many guys can get hit by a truck and
you still have at least one person around who knows how to maintain your
app. I've worked at places where a guy was left alone to program a fairly
small and straightforward--but important--application for a full year on
his own. He left the company and the thing fell apart. It had grown on
his machine like that leafy, verdant space alien from Little Shop of Horrors.
It took a full week to get it to build on anyone's machine but his. This
is simply a ridiculous position for a company to be in. Keep your Truck Factor up.

Collective ownership also feels good. Nobody wants to be the guy who, like
Charlie Bucket's father, screws the caps onto toothpaste tubes. There are
jobs like this in programming. No one wants to be the guy to point at the
little red X in the top right corner of a window and exclaim smugly,
"Yeah, that red x, that's mine. I did that.". Software developers do not
want to be on the WPA. The work is too intellectually challengine (one hopes),
and too creative (one hopes). You want to be the guy who points at the
whole application and says, "See that portal, yeah, that's mine. I did that."

When you pair program, you lose the idea of getting married to your code.
It isn't Your code. It is The code. A lot of it gets thrown away as you
refactor. Which is not to say that Big Upfront Design and PP are mutually
exclusive; they aren't. It turns out that, perhaps seemingly contrary to
my last point, that it feels good to own something, that the pride of a
meaningful job well done is very important for creative people like developers.
But you want to lose the ego-driven sense of ownership, and get more of the
pride of collective ownership. You know you've done this when you've been programming
and an hour later you don't know which of you wrote what lines. This is good.

While we're on the topic of what feels good, it is fun to Pair Program because
it helps build relationships. I see a lot of colleagues with iPods cranked to
System of a Down while they churn out code, and getting few opportunities to get
to know each other. It's important on a team to understand what everyone's skills
are so you can solve the problem in the best way, and it makes people happy to
have relationships. As someone who has something short of raw contempt for explicit
corporate team building efforts (okay, something in total excess of raw contempt), this
is a nice, easy way to really honestly be on a team--not just be told as you blink
that you're a team.

Which brings us to a myth that we can all be disabused of now: Pair Programming is
called Pair Programming becaues it is two programmers in the act of programming.
It is not called One Guy Programming and Another Guy Sitting Behind Him Asleep At
The Wheel. There are two issues here. First, managers who think that their productivity
is cut in half because there's only one compiler now are just flat out wrong. The
code is produced more quickly, because you can keep your focus for far longer when
your smart and motivated colleague is right there with you keeping you on your toes.
You can't be a schmuck. You have to get it done. You can't cut little deals with
yourself like, "I've been programming like the dickens for 7 minutes straight--I better
check my email and screw around on the Internet for an hour. I deserve it."
People throw around metrics like "Pair Programming increases productivity by 15-20%".
That may be so. It seems that way to me. I certainly don't understand how such metrics are collected, how you could compare the productivity of programmers of the same level on
problems of the same level of difficulty and determine junk like that. I just don't trust
that kind of talk. Particularly with OO code. We're always happy when we can throw code out.
This weekend I took an old utility method and cut it from 24 LOC to 8. I was so happy. The code runs faster and is easier to read, in no small part because it's shorter. It's easier to read Oliver Twist than Bleak House on a thoroughly practical level. So I'm not sure of the value of such
"studies". But I do believe just colloquially that Pair Programming makes people
more productive than the same two guys independently. And it just seems clearly to
be the case.

The second issue here is this: both people at the keyboard need to be actively,
directly involved. There can be a tendency for the backseat driver to fall asleep on
occasion. That's part of the point of Pair Programming: people get tired doing
tricky work for extended periods of time. Joel Spolsky has said, and I hear it,
that he gets about 3 good, honest, productive hours of programming a day out of
himself. That's pretty good. But they aren't always the same three hours a day.
And if you're working with another person who presumably has approximately the
same level of ability to focus, those two programmers can be more steadily productive
throughout the entire day by switching off who is driving. It is kind of a
different mindset, solving an efficient sorting algorithm than noticing that some
related functionality can be factored up into a superclass because later you know
you're going to need to do this other thing again. Both are useful in the effective
design and execution of the program, and both are valuable in terms of the company's
investment in your work, and both make a happier user. Pair Programming is reality-based
programming, and maximizes effectiveness based on how people really work, not some
idealized dream of how people would work if they were robots and not bloody people
at all.

Pair Programming improves the quality of your code. It keeps your code lean and portable.
You know what the issues up front will be as you deploy. If you have taken short cuts with your
paths or DLLs or over-indulged in the customization features of your IDE such things are brought to light almost immediately. It's a good idea in PP to switch computers every once in a while,
just to shake things up so that these sorts of issues, which do happen, get alleviated.
Your code is better the more self-contained and portable it is.

This is something that should be done anyway, but make sure everyone on your team has
code foratting templates set up identically in their IDEs. This makes it seamless when you
move from one machine to another, and helps keep code readable and maintainable and egoless.
Barney and I just have our New Java File templates set up to indicate that we are both the
author of everything we write. Like Jagger and Richards are the authors of the Stones songs.
Except of course the ones Robert Johnson wrote that they take full credit for. Bastards.

Your code is further improved in PP because your choices must be justified.
It is common to have a junior guy and a senior guy paired. This is great. It really helps
both programmers become better. But you have to have an understanding:
Whoever can make the best case for a particular implementation or use of a certain pattern is
the winner, that is, you do it his way. You don't just do it the way the most senior guy wants because he likes to pull rank and remind you of what a moron you are for not being him. Just whoever makes the best case. I understand that this will often be the most senior guy. But they can't rest on their laurels: they have to actually make the case. This makes Senior guy really know his stuff--not just recall thatsomeone once told him not to just catch Throwable and he can't remember why it's a bad idea. Senior Guy now has to remember why. And Junior Guy now learns the real reason and won't catch Throwable when left to his own devices next time. It continually reinforces good practices.

Now this can be a personality issue.  If they are both motivated and check their egos at the door, they can really improve each other's knowledge. People have complementary skills. You can't sit around all day long doing EJBs and all day long doing server admin and and all day long doing modeling and and all day long doing DHTML. There's only one All Day Long. Everybody has something
to learn from anybody. If you work at a company that has a group of Heathers who
run the whole show, be wary. Use PP to combat it and break it up. Rotate your Pairs
so that Joe who is a big 400 expert can start to learn messaging from a JMS perspective.
A week or two or a month or two later or whatever's appropriate, stick Joe with Phil
and do something else. All this will do is improve the quality of the code, give
everyone a Jeremy Bentham-like perspective on the enterprise, and get people excited
about what they're doing. They won't get in a rut. They will understand that it is supposed
to be important to them to always keep learning, drop their ego, and stay flexible.

There is a clear downside here. This can take extra time, because you aren't just
forcing Joe to screw on caps all day long, having determined that he's faster at
it than anybody. But you have to ask yerself one question: am I building a team
of smart, happy, productive programmers who write great code and love what they do?
As Dirty Harry says, "Well do you, Punk?".

Finally, remember this: one man's class is another man's API. Everything you deploy is
instant legacy code. Someone, some day, if your program is of any value at all, will have
to modify or extend or reuse what you wrote. Pair Programming helps keep you thinking
not just at the algorithm level, but thinking at the API level. You've got to do this
to be a good programmer. PP brings your code toward the middle, keeps it looking textbook,
keeps it tight and lean. It's not magic. It just helps keep you thinking this way.

So it is my view that Pair Programming, when done properly, improves your team by
positively addressing matters of code ownership, helping build real relationships,
encouraging mentoring and learning, and protecting the company's investment. It
improves your code base by helping ensure portable and lean code that has been
tested in different ways, by different eyes, and which is going to be generally
free of shortcuts and hackjobs.

Happy programming.

Presentation on JavaServer Faces, Hibernate, XDoclet

I wrote a presentation about a year ago introducting JavaServer Faces, Hibernate, and XDoclet for the Java group at my company.

We have used JavaServer Faces and XDoclet with terrific success on a few projects since that time. If you're looking for a brief overview of some of the advantages of these technologies, and a fairly good collection of links, you can check out the presentation here:

http://www.ebenhewitt.com/presentations.html

Alison Brown's Website is Up

>My wife Alison Brown has recently posted her new website. It features her current syllabi, links, and other resources.

Check it out here: http://oak.ucc.nau.edu/alb

Autoboxing and Natural Primitive Promotion in Java 5

Consider this class:

class Some<T extends Double> {
    T num;
    public Some(T num){
    }
}

This is legal, but dumb. It's dumb because Double is final, and while we can't actually
extend a final class, we can meet the contract of the parameter by passing a Double.

But note that we lose natural primitive promotion in autoboxing. That is, the following is legal:

Some<Double> s = new Some<Double>((double)24);

The primitive double is autoboxed to a Double. It is illegal to parameterize a type on a
primitive. The following is illegal:

class Illegal<double> {}

Because we lose primitive promotion in autoboxing (whether in type parameters or elsewhere),
the following is illegal:

Some<Double> s = new Some<Double>(24);

Because 24 is an int. Natural promotion in autoboxing is lost. This isn't a Generics note,
but an Autoboxing note in general. It's just something to keep in mind as an API designer,
particularly with respect to overloaded methods and varargs.

On Code Reviews

I think code reviews are crucially important to the success of a
development team. Here are some of my thoughts on how code reviews
might go for a relatively small team.

I understand that at Google they have a dedicated senior person whose
job it is to run the code reviews. That's probably terrific for their
QA. For smaller teams looking to figure out how to do them, here are
some ideas.

On Java Coding Standards
Adopt the Sun standard. Don't think about it too much. It isn't interesting.
You can find this here: http://java.sun.com/docs/codeconv/

Have all of your programmers write their code to conform with it. Their IDEs
should be set up to automatically format it this way. With Eclipse and IntelliJ
and other IDEs, you can create a template so that everyone's source physically
looks the same.

It is terribly boring to sort of drone on and on about whether your fields
belong at the top or bottom of your class, or whether your curly braces belong
on the same line or their own line.

However.

It is also, in my view, very important that everyone's stuff looks the same.
That is, it doesn't matter _that_ your fields are at the top of the class (uh, where
they should be), as long everyone on the team has them in the same place.

This is because code must be readable. If 80% of the cost of software is in the
maintenance, your stuff has to be readable by someone else so that they have the
best chance of finding where the problems are.

This assumes there is some clear set of standards regarding program structure.
Code formatting is worthless if there's no shared understanding of refactoring to
patterns among team members.

The Pragmatic Approach
So here are a few pragmatic ways to approach that matter.

Create a set of development guidelines. These include key aspects of,
for example, Bloch's book Effective Java and books like Bitter Java. These are
an obvious minimum if somehow your team is reading-adverse.
Identify general highlights from these, and publish for everyone to access
(say, on your intranet). Make sure no copyrights are being violated. I'm talking
about standard stuff here.

Add your own guidelines to this as people think of them. Have people
understand and follow these general guidelines. These include reminders such as
"Always override hashcode when you override equals" and
"Here is the definition of a Java Bean",
"Don't use the interface enum antipattern" and like that.

If your developers don't all have a strong, shared understanding of
the Gang of Four and the J2EE patterns, it can take a fairly long time to get it.
Have frequent presentations on design patterns. Have everyone in the
group research and present a different pattern or two.

I have found that if people do these three key things (write to the Sun convention,
follow basic coding guidelines and best practices, and refactoring to patterns),
their code will be clean, readable, maintainable, readily understandable,
and will have the best chance of working and being extensible and scalable.

I know that's a lot of neat marketing words, but it's just true in my
experience.

But what does that have to do with a code review? Everything. It makes
the stuff you bring to the review. You have to minimize the tension
that quickly obtains at code reviews. You also want to focus on interesting
problems and design issues, not curly braces. Set the bar at least that high,
even when your team has some junior and some senior programmers on it,
and you'll have fun and productive code reviews, not bitchy, egomaniacal showdowns.

Setting the bar at least that high also helps move each developer forward at
an appropriate pace.

Code reviews should be something that everyone looks forward to. I love the stuff I write.
I throw half of it away (bad daddy) in refactoring, but it's fun to have interesting conversations
with smart people who care about what they do.

Code reviews should be short, focused, and frequent. What has worked for me is
30 minutes or so every two or three days, first thing in the morning for each employee.
That way, the comments from the reviews can be incorporated into that day's
work, and the reviews will not be general, but be a good learning
opportunity for one or two important things.

At the end of the week, or some similar time frame, the code reviewer
can make some kind of summary statement indicating general things that
the group can focus on. This could be time consuming, and isn't necessary however.
It could be tossed on top of some time reporting or billing tool you might be subject to.

What Code Reviews Accomplish

Doing code reviews this way accomplishes a few things:
1. It helps build the team.
2. Everyone gets individual attention and thereby learns more, faster.
3. It keeps the project focused and moving forward, because people
know they will have to always have something new to bring to the
review.
4.It helps identify parts of the code that can be abstracted up,
refactored in some way, reduced, or eliminated.

Finally, reviews have the obvious benefit of being a way of identifying
people who would really rather be astronauts and ballerinas than coders.
Let those people have an opportunity to reveal their true desires by degrees
as they fail their code reviews. Then they can be let go, into the wild, to
puruse their dreams. Now I don't think "grading" code reviews is a
good idea. It feeds a sort of pervasive macho hierarchical aesthetic which I frankly
find distasteful. But there is a clear record anyway of what sorts of things
are being found in people's code.

The architect, or whoever is doing the code review, should be using it as his
review time as well. He can ask himself, is he doing a good job of
identifying and unifying the issues within use cases, refactoring the design along the way, and
shining a light on paths for developers to take to get there.

Additionally, the architect should have his code reviewed by another
member of the team in order to protect the investment that the
organization makes in the project. You don't want code in the
repository that only one person understands. This can be a disaster.
It will also keep the architect on his toes.

Keep Your Truck Factor High
If you're the guy doing the reviews and you also write code and you're such
a genius that no one else might be trusted to understand what you're writing
when left to their own pitiful devices, then it's your job to make at least
one other person understand. Maintainable code is more maintainable when your
truck factor is high.

Robert Martin is the person I first heard use the term. Your app's truck factor
is the number of people who can get hit by a truck and the company can still maintain
the app.

Take a good, hard look at your organization. What apps do you have with a truck factor of one?
Get pair programming going, even if you hate XP and adopt no other practices, and get your
truck factor up on your apps. Code reviews help keep truck factors high.

Code Reviews and Contractors
For contractors, there are somewhat different rules. If you have contractors writing
apps for your company, you've got to have their stuff reviewed in some regard. You can't
just accept the app. You have to accept the source.

Have the aim of code reviews for contractors be conforming to the spec
and making sure that the reviewer is ensuring durability of the design
in a more general way. This is not a learning experience for the
contractors or team building experience. It is clear and simple
protection of your investment.

These reviews needn't happen in person, and shouldn't. It would be a sort of enormous
waste of money and time and wouldn't be any fun. Contractors should be given a
branch of the repository or some similarly locatable place, and your
team should review that code. The architect should review the code to
make sure that the final product will incorporate well with the common
architecture of SRPMIC. But the real code review can be done by other
members of the team, so that they get used to reading code for
potential performance problems, deadlocks, general strangeness, and so
on.

I've seen a lot of projects where contractor code goes into production, and even they don't
understand the code they committed, because they don't even understand the language it's written
in (Java), because they didn't write the code. Some other guy (a previous customer in many
cases) wrote the code and it went to the big database in the sky and they start the copy and
paste machine and they're off like rabbits.

So, there are two kinds of code reviews with two different purposes. They're both crucial in
my view to your overall success.

BEA buys Plumtree

BEA announced they are buying Plumtree last week. For $200M, it's a pretty good deal.

http://www.bea.com/framework.jsp?CNT=plumtree.htm&FP=/content/news_events

I think that we'll see BEA start moving out of their sort of strictly J2EE market with this announcement and their new AquaLogic ESB. A key Plumtree advantage is that they have a lot of the Windows-based market with their app server, whose kernel is written in C++. The Java edition is relatively new. We'll see BEA broadening their image into an Enterprise Services brand, instead of Best of Breed J2EE app server company.

I think it was a smart move, since I think Plumtree is widely perceived by analysts as a portal market leader.

Don't be surprised if the real nails start driving into JSR-168's coffin as well.

Website Redesign

I redesigned my existing website at www.ebenhewitt.com. I will post a common library there soon with some general utilities.