We have lots of OSes around the office here – Ubuntu, Windows, and OSX. Of those, Ubuntu and Windows natively provide a way to lock your desktop with a keystroke (Win+L or Ctrl+Alt+Del, Enter on Windows and Ctrl+Alt+L on Ubuntu). Strangely, Mac gives no easy way to lock your desktop.

We’ve been using HotCorners for the screen saver, but who wants to touch the mouse if you don’t have to (especially when you’re racing to grab a free lunch)?

Enter Quicksilver, everyone’s favorite application interface. (There are all sorts of things you can do with Quicksilver and its various plug-ins, but you can look that up yourself.) To set up a keyboard shortcut with Quicksilver to lock your screen (hat tip to Bryan Helmkamp):

1. Create a symbolic link to your screen saver application:
   $ sudo ln -s /System/Library/Frameworks/ScreenSaver.framework/Versions/Current/Resources/ScreenSaverEngine.app/ /Applications/Screen\ Saver.app
2. Quicksilver -> Triggers -> Custom Triggers
3. Add a Hotkey
4. Find the ScreenSaverEngine by typing and press enter
5. Double-click the cell in the Trigger column
6. Choose your hotkey (I like Ctrl+Cmd+\ since it’s almost Ctrl+Alt+Del
7. Close the window (you may also need to restart QS

Now set up your System Prefs in Security -> General to require a password immediately after screen saver begins and you’re set.

Sadly, you need to do this or your screen saver will awake as soon as you release your QS shortcut. This even happens if you set QS to launch screen saver “On Release”.

Anyway, after that, lock screen is just a keystroke away.

My first thought was: there’s lots of blocking reading and writing from the database, so adding some threads should speed things up. While one thread was analyzing Bob’s energy data, another could be fetching Mary’s, while another could be updating Joe’s meta-data with the results. Or so I thought.

The more threads I added, the slower the entire thing became. It turned out that the fastest implementation was a single-threaded one. But why? It all has to do with the diminishing returns one gets from scaling out.

If you think of a task as having a serial component, which cannot be broken up concurrently, and then multiple tasks which can be done concurrently, we can analyze the returns we get by increasing the number of available processors (threads, in my case). This is Amdahl’s Law and is exemplified by the following equation (where “x” is the number of processors or threads, and “s” is the percentage of your overall task that must be serialized; “y” is the increase in speed you will see from scaling).

When you graph this, it’s pretty obvious that there are diminishing returns to adding more threads/processors (the graph below assumes that 90% of the overall job can be done concurrently). As we add threads, we get less and less of a gain in speed.
But there’s still a gain to get, so what happened to me?

Amdahl’s law is actually pretty optimistic. It doesn’t account for the overhead required to synchronize the shared data. If we account for this, with a new value “k” ( the percentage penalty for maintaining consistency), we see that increasing our processors/threads actually starts to hurt us (this equation is in red)!

In my case, almost all of this synchronization is happening within the database; it turns out that almost all the time my process needs is accessing data from the database. So, I dialed it down to only one thread, and we should be done early next week.

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.