Larry was pissing me off.

We were a year into a two-year development process. Far enough along to have confidence that we could do it, but not far enough to be sure when we would get there.

Features were claimed to be done, but each build of the product was a study in broken and frustration.

So I’d ask Larry, “Why doesn’t this feature work?”

Larry’s lengthy answer demonstrated his deep knowledge of the product, his confidence in his team, and incontrovertible evidence that they were making progress and that the feature would work “real soon now.” Larry would convey this confidence and I’d leave the conversation swimming in a pleasant sense of managed calm, but a day would pass, I’d install the next build, and shit was still broken.

I knew if I walked into Larry’s office I’d get the same fire hose of comforting reasoning regarding why we weren’t done. I also knew if I waited another 24 hours to see another pile of broken bits, I’d lose it, so I stopped, took a deep breath, and wrote myself a short list.

Seven bullets. Each representing a feature that needed to work. Not done, just working.

I took the list into Larry’s office and handed it to him: “This is the Larry Test and you need to pass it.”

Done

This is an article about choosing to be done.

Done has a lot of definitions, depending on where you’re standing in the building. Marketing thinks you’re done the first time they see a working demo. Program managers think you’re done when the deadline arrives. QA thinks they decide when it’s done because they’ve got fancy metrics to define doneness: “No high priority bugs found in the software for a week.” Ok, fine metric, but for engineering, done happens long before all of these definitions.

The issue is that an engineer’s definition of done is the perfect set of code, and left to his own devices, an engineer will endlessly improve the code on the mythic journey to done.

It’s never done. For any large project with many personalities in play, at best it’s always good enough. Sorry.

This is not an argument for mediocrity. You can toot your horn about quality and only be good enough, but I guarantee — I promise you — that you will ship with significant piles of two types of bugs: the ones you know and the ones you don’t. Engineers have an innate sense of where those bugs are, and if you don’t tell them to stop, they will merrily continue towards their goal of total elimination of all bugs.

This is why, when the time is right, you indicate to your team you’re done, and I use the Larry Test.

Are You Larry Worthy?

The art of the Larry Test is not in its writing, it’s when you choose to use it. When are you choosing to be done?

Paradoxically, it’s the engineers who will never actually be done that I size up to figure out when to land the Larry Test. I’d like to say there was an obvious measure, a clear sign that indicated it was time to pull out the Larry Test, but it’s a culmination of little signs.

• The senior engineer who worries the most saying something small but positive.
• A strange cessation of all meetings, indicating that we’ve stopped talking about how it should work.
• Hallway conversation about the bug database.

Each engineering team is different, so each set of subtle signs will be different. In a pinch, my advice is to sit each person down and ask, “Are we done?” Their answer will usually be no, but listen carefully to the size of the no. There’s done in there.

Before You Land the Larry

Poor application of the Larry Test can exacerbate a fundamental tension between managers and employees. We all have a boss, right? Wherever you are on the organization chart, part of your manager’s job is error checking. Been in this meeting? You know, the one where you bring in the project plan for the next year? It’s taken six weeks of hard work by your team to build this comprehensive and compelling plan and what does your manager do when you begin? He starts poking holes in it. Nit picking.

Show of hands. Who likes to be told what they’ve done is flawed after six weeks of hard work? I thought so.

Different managers have different communication styles and there are those where delivery of criticism feels almost pleasant. But criticism, whether it’s constructive or destructive, coming from the guy who signs the checks often triggers the knee-jerk negative “I did something wrong” vibe.

Reactions to this criticism vary: “He’s just trying to show he has value by poking random holes in our hard work.”

No, he’s not.

What your boss has that you do not is, hopefully, more experience. What he should be able to do after looking at a situation you’ve been staring at for a month is say, “Yeah, I’ve seen this before and this is how this is going to play out.”

It’s annoying. “Why did he wait a month to say something us? We’ve been wasting our time!”

No again. Part of your job is to become your boss. What you are doing while stumbling to and fro is finding and building the experience your boss already has. The trick and the art is, how long did your boss let you stumble? I mean learn.

There’s a fine line between managerial insight and incompetence. Your job, and your manager’s, is to let your team wander long enough to find that experience.

In the case of the Larry Test, your job is to find the precise moment to tell the team it’s time to be done. Do it too early and you’re going to look out of touch. Do it too late and you’re going to be, well, late.

An Evolving Done

I wrote the original Larry Test on a yellow Post-it note. I wrote it at midnight on a Sunday night after the team had worked the entire weekend, but the bits were still all over the floor. The Larry Test was not comprehensive, nor was it even readable. It was me, in the middle of night, thinking, “What has to work?”

Your Larry Test will differ. Maybe it’s not features you need working, but performance. I don’t know what you do, so I can’t tell you what to measure, but the point is not entirely in defining the test. The point is: when are you going to stop the design and stop the development and communicate that it’s time to be done?

No one really knew about my Larry Test for a week. It was just for Larry and I, but his team figured it out. After a week of Larry repeatedly hammering, “These are the 7 things that will demonstrate that we’re serious about being done”, there was a version of the sticky stuck to the corner of everyone’s display,

This is my test and I need to pass it.