Management Are we done?

The Larry Test

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.

22 Responses

  1. Rands, word ordering seems off at the start of paragraph 6 under ‘Before you Land the Larry’.

  2. Nevermind, it’s my reading that’s a bit off :-\

  3. Quite entertaining but still very true.

    Defining what has to be done, to be done, is not a trivial problem. At least not in my experience. I myself altough only half techie do still have this, this needs to be perfected fever.

    Blogposts like this remind me that there needs to be a good enough somewhere. Thank you. 🙂

  4. Ironic. Its 12:38am on a Sunday… er Monday now, and I am staring at a project that needs to have its first draft done in about 8 hours for review by the client. Going to be a long night regardless of how I define done.

    Nice post. Was a good break and very appropriate for me tonight.

  5. This is where agile documentation / test driven development really helps.

    TDD:

    Your engineers go through and make a prototype that only just passes any unit test it is put through.

    And then…. repeat.

    Simple – its driven by people actually requiring small facts, like “Hey, a Job can’t have two Addresses!”.

    Agile documentation:

    Its a way of naming your tests so that it makes human readable documents when run through a tool like PHPUnit.

    JobTest::testShouldNotHaveTwoAddresses() { … }

    JobTest::testShouldHaveOneAddress() { … }

    Generates

    JobTest:

    * Should not have two addresses

    * Should have one address

    Really simple, also.

    You just require your engineers to set this up so that it runs hourly or nightly; and the mantra of each morning is: “Who broke it, let’s fix it”.

    Throw a creative user interface designer or three on top of that, and your project will be fine.

    If it isn’t; take option 2; fire Larry – he’s doin’ it wrong.

  6. Now here is a project management tool that should work well beyond the domain of webdesign or software development. I remember applications and pitches for projects that we worked on far too long because we didn’t ask ourselves soon enough what we need to define now, and what could actually come later.

    I guess this is the second half of your question “What needs to work?”, Rands: “What can happen later?”

  7. An engineering manager I worked for had the following sign on his desk: “There comes a time in the history of every project when it is necessary to shoot the engineers and start production.”

    And I agree with Daniel, it’s time to say “Larry, meet Agile – Agile, Larry”.

  8. BucyrusMo 8 years ago

    Great article.

    I don’t work on a development team as described here, but the 2 big halves of this article make me ask:

    Instead of perpetuating excuses and grumbling about management …

    1) Am I choosing to be done ?

    2) Am I becoming my own boss ?

  9. In my project management class in college, the instructor always said the most important thing you need to know is “When am I done?”

    Well said.

  10. Of course, the unspoken part of the Larry Test is that once it is set, it doesn’t change for the given project it is being applied to. Far to often, the manager giving the Larry Test changes the features that need to be done, leaving the team in perpetual crisis mode, as each feature gets half implemented and then abandoned as the next takes priority.

    The Larry Test is certainly useful, but it only works if both sides uphold their end of the bargain.

  11. Great article, seems natural in its truth.

    I have also noticed the 95%DONE personalities but not in case of everlasting bug fixing but just in task completion.

    They seem to have innate need to have something TO BE DONE/COMPLETED.

    Having it DONE/COMPLETED would kill them.

  12. And the cousin is “was it successful?” And the answer depend on where you place the finish line.

  13. Beautiful piece of writing.

    Thanks!

  14. Terrific post, Rands. Thanks.

  15. An excellent post. Also appreciated Endi’s comment about the fear of being done. Your post and Endi’s comment have application far beyond the world of software engineers. In the surreal world of lawyers, there is a circle of hell inhabited by attorneys who can never finish working on their contracts or briefs because the document is never perfect. A nearby circle of hell is the one inhabited by attorneys for whom no detail is too small (the folks who don’t understand what is and what is not important) with the result that every detail receives equal attention. Needless to say the denizens of these two circles of hell believe (in good faith and with all their hearts) that they are zealously pursuing the best interests of their clients and that the rest of the world is composed of slackers (or worse). Needless to say, these traits result in the work product being late and expensive. Also, at the risk of becoming the subject of lawyer hate mail, there is definitely a point of diminishing returns (never recognized by the denizens of these two circles of hell). This behavior also impacts the rest of the legal team, for whom this work may be precatory (as lawyers say) to work they must then do under greater than necessary time pressure. Perhaps the most stunning turn is that these very lawyers then wonder why clients are unhappy. A question that is usually followed with a statement denigrating the client’s intelligence and inability to understand the legal process.

  16. 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.

    You know, I’ve heard this repeated endlessly by numerous managers, technical and not, with whom I’ve been associated, and, frankly, in my experience it’s bullshit. No responsible engineer (hell, no irresponsible engineer) that I’ve ever worked with has exhibited this tendency. They, and I, have all worked on code until we’re satisified that it meets the requirement and passes basic validity checks, and then it’s handed over to QA.

    This trope about ‘if it were left to the engineers, nothing would ever get done’ is, if you ask me, simply an excuse for managers to justify their existences. I’m sure something along those lines was muttered by one of the shits in a suit who pushed Columbia onto the pad in the middle of winter.

  17. That was Challenger, of course. Columbia was a different management failure.

  18. Sean Clauson 8 years ago

    @Mike – From my experience, young ‘hackers’ tend to chase perfection, and hackers approach their craft more like an artist than an engineer (hence Steve Jobs’ famous quote, “Real Artists Ship”).

    It takes some time for young “hackers” to become “responsible” engineers. Some never get there. Maybe you’ve not had much experience with people at this level of development (or passion)?

  19. @Mike

    I assure you that majority of engineers I have worked with need a lot of direction on what to invest their time in, and what not to. In my experience it is comparatively rare to find engineers that really focus on requirements as they develop the technical solutions, most are satisfied with providing function but cannot be accused of satisfying cost, maintainability, manufacturability or a host of other DFX topics. I work as a systems engineer and we develop reasonably complex food packaging systems.

  20. Charles 8 years ago

    @Mike, Sean, and Fox

    I agree with Mike that engineers (hardware or software) are not head in the cloud idealists. Developers and engineers are almost always interested in solving the problems at hand. Issues do occur when priorities are not *communicated* properly. Making that (patronizingly named) “Larry Test” didn’t necessarily pull Larry’s head out of the clouds, but it sure clarified things for him. Perhaps that sort of clarification should have been pursued more diligently throughout the project?

    I don’t agree with the rest of Mike’s general characterization of management. That’s just more ill will that doesn’t help anything. Of course, I realize Mike was responding to the apparent insult to engineers.

    As far as what Mike and Sean said, the only “direction” that I and almost every engineer I’ve ever worked with need are a clear indication of what problems and projects are the priority. This means making sure the engineers and developers are kept well informed about company and project priorities. This also means including the developers and engineers in this process to get appropriate feedback. Not all decisions should be unilateral decisions from management to engineering. Management may have more information about company and project direction, but they often have much less information about development issues or limitations, and I’ve never known an engineer who isn’t constantly considering cost issues. I have no idea what sort of “engineers” you must work with, Fox, but I hope I never run into them.

    I assure you that when appropriate communication is maintained your engineers and developers will get their jobs done without any hand holding or baby sitting. If you find yourself baby sitting, then you should consider the possibility that you’ve hired the wrong people or that you’ve created an ineffective work environment.

  21. DANIEL O’CONNOR you have a false sense of security

  22. This is right on. Software timing is an output, not an input (as I wrote here)

    But that said, there need s to be *some* way to move projects along past minutiae. Clarifiying the importance of priorities in projects is exactly the way to do it.