Clicking around google’s well-documented “get started” guides, it looked like they haven’t made their client JARs available in any MVN repos anywhere.  There is a (not-google-sponsored) source forge project that points to a sonatype repo, but instead of adding another 3rd party repo to our small but growing list, I figured it’d be easier for small proof of concept purposes to just manually install the google JARs in OPOWER’s repo (thereby making them accessible to all our developer’s boxes).

It quickly became clear that the number of JARs google ships with makes it faster and less error prone to script the mvn repo installation than doing manual command line copy & pasting.  Lo, my gift to the world:

• Grab latest JARs from the “gdata-java” link here: http://code.google.com/p/gdata-java-client/downloads/list
• Unzip on the server hosting your company’s mvn repo
• cd down in to ./gdata/java/lib
• Make a file ‘installall.pl’ in that lib directory:

#!/usr/bin/perl -w

my @jars = `ls *.jar`;
chomp(@jars);
foreach my $jar (@jars) {
  if($jar =~ /(.*)-(\d\.\d)\.jar/) {
    my $cmd = "./install.pl --artifactId $1 --version $2 --jar $jar";
    open(CMD, "$cmd|") or die "Could not execute $cmd $!";
    while(<CMD>) {
       print $_;
    }
   close(CMD);
  }
}

• Still in that directory, make another file ‘install.pl’:

#!/usr/bin/perl -w

use strict;
use warnings;
use Getopt::Long;

sub usage();

my $artifactId;
my $version;
my $jar;
GetOptions('artifactId=s' => \$artifactId ,
           'version=s' => \$version,
           'jar' => \$jar);
die usage() unless ($artifactId && $version && $jar);

my $cmd = "mvn deploy:deploy-file " .
      "-DgroupId=com.google.gdata " .
      "-DartifactId=$artifactId " .
      "-Dversion=$version " .
      "-Dfile=$jar " .
      "-Dpackaging=jar " .
      "-DgeneratePom=true " .
      "-Durl=file:///opt/mvn_repo " .  <---  change this for your env
      "-Drepository=opower_local";  <--- change this for your env
print "executing command = $cmd\n";
$cmd = "date";
open(CMD, "$cmd|") or die "Could not exec $cmd $!";
while(<CMD>) {
    print $_;
}
close(CMD);

sub usage() {
    print "Usage: ./install.pl [--artifactId artifactId] [--version version] [--jar jarfile]\n";
    print "Example: ./install.pl --artifactId gdata-webmastertools --version 1.0 --jar gdata-webmastertools-1.0.jar\n";
    exit 1;
}

• Don’t forget to chmod 755 *.pl
• Then just run ./installall.pl and all those google JARs should get installed in your repo

That assumes the “mvn” executable was in your path and that you run the scripts from within the same directory as all the JARs, but it’s easily modified for whatever your situation may be.

Note that relative to ./lib there are 2 jars in ../deps/ that you should also install in your repo because the google JARs to avoid ClassNotFoundExceptions in some runtime code paths.

Once in, you should be able to boot strap a mvn client project against a Google Data source with a pom not too dissimilar from:

<?xml version="1.0" encoding="UTF-8"?>
<project xmlns="http://maven.apache.org/POM/4.0.0" xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance" xsi:schemaLocation="http://maven.apache.org/POM/4.0.0 http://maven.apache.org/maven-v4_0_0.xsd">
  <modelVersion>4.0.0</modelVersion>
  <artifactId>foo</artifactId>
  <packaging>jar</packaging>
  <version>1.0.0-SNAPSHOT</version>
  <name>Google Client Example</name>

  <scm>
    <developerConnection>foo</developerConnection>
  </scm>

  <dependencies>
    <dependency>
        <groupId>com.google.gdata</groupId>
        <artifactId>gdata-core</artifactId>
        <version>1.0</version>
    </dependency>
    <dependency>
        <groupId>com.google.gdata</groupId>
        <artifactId>gdata-analytics</artifactId>
        <version>2.1</version>
    </dependency>
    <dependency>
        <groupId>com.google.gdata</groupId>
        <artifactId>gdata-client</artifactId>
        <version>1.0</version>
    </dependency>
    <dependency>
        <groupId>com.google</groupId>
        <artifactId>google-collect</artifactId>
        <version>1.0-rc1</version>
    </dependency>
  </dependencies>
</project>

Goodhart’s Law: Any observed statistical regularity will tend to collapse once pressure is placed upon it for control purposes

Here at OPOWER, developers and product managers don’t deal with KPIs on a day-to-day basis….I think it’s mostly a management-level “let’s starting capturing some numbers over several months and see if there’s anything out-of-whack” kind of thing.

In terms of development KPIs, some of the things we thought it might be interesting to collect included:

• story points delivered per iteration
• % of story points (aggregate) done in an iteration that were planned at the beginning
• % QA coverage of production (automated)
• etc.

The “story points delivered per iteration” is, I think, precisely the kind of thing Goodhart was talking about when he made up his law.  That said, we are a business and we are expected to work and be productive, so it isn’t exactly a satisfying for a VP or CEO to hear from their dev team “sorry, you can’t measure us because we’ll just skew the measurement number to please you.”  So what’s management to do with their IT cabal?

Assuming you could normalize what story points mean across different teams, and assuming you can account for “point inflation” and assuming you accurately tracked vacations and network outages and late requirements and all the other stuff that goes along with uncertainty in exactly how much gets delivered in an iteration, must you also assume that the team gradually skews the number to meet the goal?  What if the goal was kept secret?  What if the team didn’t know they were being measured?  That’s hardly a way to foster a healthy relationship between management and product development.

One way around this dilemma is to find some totally objective metric in the software engineering process.  In other words, if you could apply KPIs to “number of sprockets coming off the assembly line such that each sprocket is within .1% tolerance,” what is a similar kind of thing in our iteration process we could measure?  I.e., one that doesn’t easily fall prey to inflation or manipulation?  If you can find something like that, lemme know.  Until then, I won’t be holding my breath.

Another possible option would be to go ahead and publicly measure highly subjective KPIs anyway and ask the measurees (us) to be as objective as possible when measuring.  I.e., fly in the face of Goodhart’s Law.  After all, it’s just a Law.  Like De Morgan’s Law, except maybe with a bit more wiggle room.

There have been a couple articles recently about the effects of sitting in a chair all day that pushed me to action.  This article from business week was particularly eye opening.

OPOWER is super cool about empowering developers to be more productive/comfortable/happy/etc so getting approval for expensing some generic Ikea furniture was as easy as a head nod.  A couple weekends ago, I drove down to Ikea and picked up an Utby desk for about $100 and an Ekby Viktor shelf with Capita legs for another $20 or so.  I didn’t think the desk by itself was going to be quite at the recommended elbow height, so I swung by Home Depot and got 4 cinder blocks too.

I ended up putting a stack of paper between my monitor and the shelf to really get it up at eye level and I’m pretty happy with the way it turned out:

Dave’s setup is very similar, but he seems to like focusing down on his single screen whereas I like having a couple monitors at different focus points where I can physically distinguish tasks (documentation, music, images on my laptop off to the side and development tasks on the main monitor straight ahead).

Dave at his standing desk

It’s been a couple weeks since I switched and I can draw the following conclusions so far:

• Your feet hurt like a sonofabitch at the end of 8, 9, 10 hours if you’re not used to standing that whole time
• A little bar stool or some off-the-floor step helps a lot in shifting your weight around so you’re not always bearing down on both heels
• My back feels a ton better
• I feel more productive (though I don’t know empirically if I actually am) because (a) I feel really focused on the monitor right in front of me — more so than when sitting down and (b) I’m a little more self-conscious of my screen being visible to everyone walking by, so I suspect I’ve got a higher percentage of work-related stuff on my screen at all times than I did before.

To the disgust of myself and my wife, I collected shavings for approximately 4 months in a plastic cream cheese jar labeled “Not Cream Cheese.”

This last weekend, I took a trip to AC Moore Arts & Crafts and bought some clay.  I fashioned a mold into that clay of a mustache that would dominate all other mustaches.

Into that mold, I poured elmer’s glue, hair shavings, 14 gauge electrical copper wiring, more hair, more glue, more hair.

This morning, the plan was to simply glue the assembled mustache on to my real mustache.  Unfortunately, the plan involved entirely too much super glue and the assembled mustache pieces proved to be entirely too heavy.  My previous experience with krazy-glue-on-skin is probably like most people’s…stick your thumb and index finger together.  Thanks to callouses, a lack of hair on your fingertips and the relative strength of your digits, it’s not that big of a deal.  I also don’t remember the glue burning like lava on contact.

A split second before squirting a liberal does of krazy glue on the mustache I wondered: “is this really a good idea?”  But not wanting to pysch myself out, I quickly brought the assembled mustache up to my lip and pressed down hard.

The first thing I remember thinking is that this was going to look really good.  Like, maybe champion-quality entry.

That thought was quickly replaced with a rising alarm about the rapidly increasing burning sensation I was experiencing between the mustache and my lip.  That alarm was then replaced with the growing realization that I was inhaling quite a bit of vapor and that my throat was starting to burn.

Not-quite-panicked, but not totally calm either, I gently tried to remove the mustache and got as far as pulling my lip about an inch off my face before giving up.  Over the next 10 minutes I was able to saw, snip and shave the ’stache down with a combination of electric shaver, electrical pliers, scissors and razor blade.  By that time, of course, the fumes had dissipated and the burning was just a low heat and my grand mustache plans were wrecked.

The redness of my eyes is due to the fumes and pain.

There’s always 2011…

We here at OPOWER use Alfresco Community 3.2 as a glorified “XML editing tool” that was easy to setup, configure and hand over to the business to allow them to contribute XML-based content that our applications can consume. As a F/LOSS solution, it’s fit our needs pretty well and is generally a low-maintenance piece of our infrastructure.

I attribute my “low maintenance” characterization of an Alfresco installation mostly to the patience of my small user base, who are very accommodating to the quirks and limitations of the installed (and neglected) instance.

The 3.3 lunch and learn was intro’d by Chris from SiteWorx who surveyed the CMS landscape and equated the emerging CMIS spec as “content’s ODBC” which I thought to be a quite fitting analogy.

Richard Im from Alfresco then spoke for about 45 minutes about the new features Alfresco 3.3 contained:

WCM Improvements

• new web-based editor, reminiscent of Interwoven’s in-context editor from the 6.5/7.0 era
• new bi-directional deployment capabilities (including addition of “delivery server” infrastructure possibilities like several other CMS offerings)
• “Straight through” publishing without workflows
• google-like search on metadata attributes

Share

• Evolving share into more of a bit-for-bit replacement of the “traditional” UI (which Richard referred to as “DM”… “document manager?”)
• Permission control a la DM
• Rules and Actions just like in DM
• Data Lists (like Share Point’s project lists)

I asked the question: “what’s the medium-term road map for DM, if Alfresco seems intent on mirroring all(?) functionality in the traditional UI via the /share context?”  Richard wouldn’t definitively say that the traditional app is going to be deprecated any time soon, but it certainly appears that way…

“Integration” improvements

I think this suite of improvements is geared towards the enterprise crowd:

• Full CMIS 1.0 spec implemented as of 3.3 (the only open source implementation known to do so)
• ACLs
• Change Logs
• Additional SOA/REST services and support
• Ability to save off google docs in alfresco for management (!)

My big take-aways from the lunch and Q&A session was that Alfresco’s 3.3 feature list and 3.4 direction seem to put them on more of a competitive footing with monster ECM vendors like Interwoven.  It’s maybe an odd direction for an open source project to steer because while Alfresco certainly employs their own development team, I’m not sure how much community interest there is in contributing to some of the more mundane enterprise ECM concerns that need to be built or integrated.  On the other hand, Alfresco, Inc. does survive with enterprise support contracts that smaller shops like mine are unlikely to ever pay top-dollar for, so maybe it’s a long term survival strategy.

Long term, I’m interested in exploring architectures available to us with a SOA-enabled CMIS layer and eventually ditch the custom-DAO layer we’re running right now against Alfresco-exported XML flat files.  Even if that never happens, it’s exciting to see the kinds of complexity that open source projects are able to attack.

We’ve got a new kitchen area that’s big enough to hold the company for a stand-up meeting…we haven’t had that capability for what seems like forever. There’s a pantry off to the left of the image (not shown) stocked with drinks, chips, pens and pads.

We’ve got a nice lobby area too…through the windows in the background one can see the National Cathedral, Georgetown and most of Northwest DC. One of the things we’re all looking forward to most about the new space is the number of break away areas and conference rooms.

Our working space is, as you can see, very open.  In the old office, that was occasionally annoying because sound echoed off the relatively confined space and amplified the drone of office sounds.  This space is well carpeted and more “open” so it seems quite a bit quieter.
The guy in the middle of this picture actually does the “Messin’ with Sasquatch” series of commercials for Jack Links Beef Jerkey.  He got the part because he needed less time in costume than the other actors.

The new location means a whole new suite of lunch places to try out.  That’s a relief because the Chop’t -> Chipotle -> Chop’t cycle was wearing pretty thin back in Rosslyn.

• Iteration N, Week 1 = Design for iteration N and 2nd week of QA for iteration N-1
• Iteration N, Week 2 = Development
• Iteration N, Week 3 = Development
• Iteration N, Week 4 = 1st week of QA for iteration N
• Iteration N, Week 5 / Iteration N +1, Week 1 = 2nd week of QA for iteration N, design for iteration N + 1

We started to notice a couple things that have caused us to try out a new schedule in our upcoming 6th iteration.

First, we realized that we left very little time for fit to hit the shan.  If we had a tough QA cycle, we didn’t design enough.  If we didn’t design enough, we underestimated how much development would be needed (i.e. too many story points).  If we had too many story points, we’d go in to QA late.  And the cycle repeats.

Note that many of you Agile purists out there will cringe at the above description, especially this sentence: “If we had too many story points, we’d go in to QA late.”

I know.  We cringed too.

We’re committing to a couple new explicit practices going in to our next iterations:

1. More formal velocity check-ins.  If less than 50% of our story points are closed by COB of the first Friday, we should have a come-to-jeebus meeting on Monday morning.
2. We absolutely need to respect the impact that dedicated design time has on the effectiveness of everything down-stream.  It’s too easy to say “Agile” as a synonym for “code by the seat of your pants,” but that’s not what it’s about and we know that.  We just need to get better at dedicating time to it.

So with those ideas in mind, we’re moving to something like the following:

It’s a five-week iteration, with 2 solid weeks built in for QA and 1 dedicated week of design.

I think if we can get to a point where our regression and automation testing is good enough (and we develop enough confidence our automated tests), that we may be able to get back to a 4 week cycle.  In the mean time, we’re going to see if we can actually go faster by slowing down.

Stay tuned!

Well, we here at OPOWER loved our Duck Hunt, so we’ve been attempting to use “Agile” for the last 5 months or so. Agile means a lot of things to a lot of people, so I’ll spell out what it means for us and then reflect on some of the pros, cons, and room-for-improvement in our practice.

• <cringe>Embrace change</cringe> (duh)…but especially in this startup environment, we need to remember to do no more than is necessary, because any “extra mile” functionality is likely to be totally unused as priorities and direction changes.
• Be scientific about development…measure, measure measure.  We track velocities, average-open-days-per-bug-by-severity, etc.
• “Individuals and interactions over processes and tools”…we self-organize, aren’t afraid to try new combinations of responsibilities and assignments, provide regular feedback to each other and we don’t dictate a development environment or technology stack.

The best thing about the technical side of this company is that the entire development team and project management team is on-board with the idea of rapid iterations, continuous improvement and a focus on technical excellent and “maximizing the amount of work not done.”

This manifests itself in several practices that I’d chalk up in the “pro” column:

• Light weight documentation…use wikis and person-to-person contact (recorded on bug tickets for posterity) to flush out designs and requirement.
• Continuous integration and continuous improvement (we just installed Sonar last week…we’ll blog about its effectiveness later)
• Regular code reviews, 360 reviews, and “how did we collectively perform this iteration” meetings
• Few formal meetings, many informal, impromptu “drive bys”

But the best thing about our Agile environment right now is that it is a work-in-progress “process framework” that repeats quickly enough for us to remember what to improve.

What do I mean by that?

It’s my impression that on the longer, more drawn-out software engagements (say…6 or 12 months), you can make a series of mistakes in the design phase, the build phase, the qa phase, etc. and then by the time you’re on the next project you repeat all those mistakes again because it’s been 6 or 12 months since you last learned your lesson.  Instead of concrete lessons, you develop a career full of “gut instincts.”

We’re still honing in on the right amount of measurement and process for OPOWER, but because we’re all on board with the idea of quick-hit iterations with a continuous focus on improvement, I have high hopes for our ability to become (stay?) a top-notch software engineering organization.

There’s lots of room for improvement, that I think I’ll save for another post on another day.  We could definitely stand to “communicate out” more– with the product team and with our operations team.  We need to do a better job of making sure our iterations are lining up with the corporate strategy.  We could improve on the whole “customer collaboration over contract negotiation” part of the manifesto.  But you can only squeeze that trigger so fast, right?

I recently converted the attribute of our Person POJO that stored a user’s email address from a java.lang.String to a javax.mail.InternetAddress.  Call it not enough testing or lack of imagination, but I introduced a Null Pointer Exception in a back-office web flow where a new user is created for our customer service application.  When a new CSR account is created and the email address is left blank, an NPE gets thrown up.  Embarrassing, but easy to fix, right?

Just looking at the stack trace narrows it down immediately:

2009-09-09 16:56:53,636 WARN  [btpool0-1] [REPORT] [WARN] Handler execution resulted in exception
java.lang.NullPointerException
	at javax.mail.internet.InternetAddress.parse(InternetAddress.java:609)
	at javax.mail.internet.InternetAddress.parse(InternetAddress.java:569)
	at javax.mail.internet.InternetAddress.(InternetAddress.java:105)
	at poscore.db.InternetAddressUserType.deepCopy(InternetAddressUserType.java:93)
	at org.hibernate.type.CustomType.deepCopy(CustomType.java:179)
	at org.hibernate.type.TypeFactory.deepCopy(TypeFactory.java:374)

Ahh…yeah…that custom hibernate type I wrote to translate VARCHARs to InternetAddresses and vice versa. Ok, what does that deep copy method look like?

    public Object deepCopy(Object value) throws HibernateException {
        if(value == null) {
            return null;
        }
        InternetAddress original = (InternetAddress)value;
        InternetAddress copy = null;
        try {
            copy = new InternetAddress(original.getAddress());
        }
        catch (AddressException ex) {
            throw new HibernateException("Unable to deep copy email address '" + original.getAddress() + "'");
        }
        return copy;
    }

It turns out, the error is right here:

            copy = new InternetAddress(original.getAddress());

You can’t pass a null to the InternetAddress constructor. It was late in the day and I must not have internalized that there’s no way value or original could be null, because my first instinct was that the NPE was actually the result of calling “.getAddress()” on a null original object….not that the constructor can’t take a null.

While I was on that assumption (that it was the original object that was null), I fired up my debugger and got confused by what appeared to be null-checks failing to check nulls. Check out this screen shot of the NPE about to be thrown after what appears to be 2 null checks failing to prevent the NPE:

The arrows marked (A) and (B) shows what appear to be null objects passing null checks (in the top pane) even though they’re being reported as null (in the bottom pane). The green line (C) shows the code falling through to that line just before it throws up the NPE.

Of course, value and original aren’t null at all…it’s just that their .toString() methods report them to be null. Here’s the InternetAddress.toString method:

  276       public String toString() {
  277   	if (encodedPersonal == null && personal != null)
  278   	    try {
  279   		encodedPersonal = MimeUtility.encodeWord(personal);
  280   	    } catch (UnsupportedEncodingException ex) { }
  281
  282   	if (encodedPersonal != null)
  283   	    return quotePhrase(encodedPersonal) + " <" + address + ">";
  284   	else if (isGroup() || isSimple())
  285   	    return address;
  286   	else
  287   	    return "<" + address + ">";
  288       }

In my situation, I fell in to the “else if(isGroup() || isSimple())” case, which returns address, which is null, so the .toString() for the whole InternetAddress object is “null.”

I think the toString() method could benefit from another null-check right at line 284, which would mean an InternetAddress object with a null internal address String would display as “<null>”…that’s a more immediate clue that the object itself isn’t null.

You cruise in to the office at 8:45, get your coffee, check the reddits, and ignore that email from your parents asking if their computer picked up a virus because McAfee won’t stop popping up a tooltray icon helpfully informing them that they’re totally vulnerable. Right around 9:15, you get motivated to tackle that 2 point user story for the current iteration.

You head over to the wiki, check out the specs for the requirement, find out what the Trac ticket number is and see if there are any comments with last minute advice or dependencies. None? Good. . . let’s get started!

Oh, huh. . . it’s 9:40. There’s that all-hands meeting at 10 o’clock. I could get started, but I’m not really going to get anything done in 20 minutes really….and that link to the keyboard-cat-three-wolf-t-shirt did look interesting.

The 10 o’clock meeting runs a little long, and then there’s the lunch train, and suddenly it’s the afternoon and you haven’t been in The Zone once.

The Zone

We’ve all been in The Zone – that magical place where time appears to stop and you rock out an insane amount of code in what seems like 10 minutes, but when you look up from your keyboard the sun is down and the cleaning crew is giving you a weird look because you didn’t realize you were trying to sing along to Sigur Ros.

Trying to force yourself into The Zone is like trying to force yourself to see through those stereograms (hint: it’s always a Schooner). And as hard as it is to get in The Zone, it’s annoying easily to get out of The Zone.

There are a lot of recommendations out there to help create “zone-friendly” work places including:

• separate offices
• ambient music
• leaving something intentionally broken the night before to give you that excuse to dive in the next morning
• shift your tasks to the upper right
• Paul Graham’s thoughts on the matter
• etc. etc.

We were wrapping up our all-hands meeting yesterday when the ever-perceptive Dave noted that our weekly meeting schedules were really not all that Zone-Friendly. With a couple of exceptions, we had standing meetings along the following schedule:

And keep in mind, that’s just the standing meetings, so it’s the bare-minimum one would expect. Now let’s add some “procrastination shading” to that calendar to demonstrate the actual standing meeting impact:

If we shuffled some meetings around (especially around the meat of the middle of the week), I think we could end up “finding” 2 or 3 hours a week more conducive to The Zone:

Of course, this is an idealized example, but it’s something we’re thinking about and playing with.

What do you guys out there in development land do? Any recommendations of particular effectiveness?