Writer’s Workshop: Double It and Add 30

Image by TeroVesalainen from Pixabay

I have never been one for lists, task lists or others. This was not always appreciated when I was working in programming. I’d be assigned a project and start right in on it, and more often than not would get the job done on time and usually exactly what the client (internal or external) wanted, or close enough that I could clean it up in a short amount of time. As far as I was concerned, coming up with a detailed plan and isolating the tasks required to do the project was a waste of time and a pain in the ass.

Nevertheless, I would often find myself in the position of having to come up with detailed plans and estimate the time it would take to complete each task, after which I’d have to cope with a manager who would then want to sit down with me on a regular basis to go over said list, checking off the tasks that had been completed and to see if my estimates for the time required to finish the remaining tasks and finish the project. At times, I would be halfway done with a project before I delivered the estimate, at which point I would turn in an estimate showing the tasks that were already finished and a list of the things that had yet to be started. And of course I’d get chewed out for doing things that way, but hey, the project was half finished, so who cared, right?

My manager, of course, was less interested in whether I could do something than in knowing how I’d do it so he could pass it on to someone else. Which I never quite understood. Why do I have to come up with what I thought it would take a junior programmer to complete a project when I knew I could finish it in a couple of long days?

So I developed a system: when asked to estimate a project, I’d figure out what it would take me to get it done, double it and add 30 hours. If a project would take me 20 hours, I would give an estimate of 70 hours. If they asked me to justify it, I’d come up with a plan (research, 7 hours; coding, 35 hours; testing and debugging, 28 hours) that did just that. And more often than not, that was how long it took.

Ain’t I a stinker?

19 thoughts on “Writer’s Workshop: Double It and Add 30

  1. Kinda a stinker, but also, really hardworking and efficient, which is ultimately what they paid you for, so…
    At my job, no one micromanages, so I’m expected to solve my own problems and I appreciate that. I don’t think my bosses would ever expect me to write a training or describe my procedure. That would take too long, and I have actual work to do.

    Like

    1. Scott Adams (the Dilbert guy) talks about “one-off” activities, which are activities that don’t add any value, such as writing marketing materials versus writing instructions on how to write marketing materials. I always thought that writing specs for junior programmers was a one-off activity. It was easier for me to just do it than it was to write up what I was doing so that a junior person could do it. I could just do it and let the guy look over my shoulder…

      Liked by 1 person

  2. I never understood why, in the workplace, you would need to detail such specifics – I understand for time purposes, but the other details, the how? Seems like management should just be concerned about getting the project done in the specified amount of time. But like you said, they want to know how long and how, so they can pass the info along to someone else.

    Kim

    Like

    1. Anal-retentive management. I understand if the analyst is moving on (either to a bigger project or to greener pastures), but with some managers (I’m thinking of one in particular), I think they do it just to screw with you.

      Like

  3. Your solution reminds me of Mr Scott from the Original Series Star Trek? As a Star Fleet engineer, he had a reputation as being a “miracle worker” getting things done faster then expected, while really he used the same technique you did. Mr. Scott admitted in one of the movies that he always doubled his repair time estimates so when he got done “early” amazed everyone and that’s how he earned his reputation. Seems a tried and true solution to task estimates.

    Like

  4. John,

    I’m like you who cares how you went about it as long as you got the job done accurately and efficiently. Some bosses want to display the authority by giving you stupid extra stuff to do. Maybe it’s because his boss is asking him to do something stupid, too. And, yes you are a stinker!

    Like

  5. Great strategy, John! I had a manager that wanted a detailed list and outline before we started every task. It took longer to do the list and outline then it did to complete the task. Drove me nuts!

    Like

  6. I used to find that planning was vital, but I was often involved in multi-man-year projects. But I too had rules – things like the minimum task was a half-day, the maximum task was 2 weeks. If something was longer than 2 weeks, I needed to think it through in more detail to break it down some more. But it was surprisingly accurate in the end. I was in the same kinda game.

    Like

    1. The bigger the project, the more you need a plan. They never trusted me to do long-range planning for a major development project (they might have if I stayed longer; I left that job after four years), but I probably would have started it at a year and worked from there.

      Liked by 1 person

Comments are closed.