How long will it take?

Full article

One of the more grating questions you might get as a developer is, how long will this take? Or even better, after you've spent a week digging into something (and that familiar self-doubt is working its magic), how much longer will this take?

It's not an unreasonable question, really. We're all trying to manage expectations, all day long. If I contract with someone to work on my house, the project may take 2-3 days or 2-3 weeks. If it's big enough, 2-3 months.  All of those are valid estimates given the complexity of the work and the inevitable surprises, but there's two answers I wouldn't expect. One is, "as long as it takes". The other is, "by the end of the day"... every day for 3 weeks.

But I feel like we devs fall into that exact trap all the time. Maybe we forget that we're all contractors, working on a bunch of mini-projects until either we or the company decides to part ways. Maybe we just don't want to let the team down. Just a few more hours, and we'll have it done. Okay maybe not, but just a few more.

I don't pretend to have things figured out. I'm just as guilty about oversimplifying and underestimating as anyone. But the question remains: How can we do better?

Plan

If you're in the same boat as me, here's some questions we might ask ourselves:

  • What's being asked of me right at this moment, with this piece of work?
  • Do I have to get anyone else involved, for a database change, or to modify a server?
  • Does it touch parts of the system I'm unfamiliar with? How will I learn enough about them to do this work?
  • Do I know where the code for this piece of work lives (or will live)? Is it just one project, or multiple? A lot of web work requires changes to the front-end, back-end, one or more APIs, etc.
  • How will I know when the coding portion is "done"? Where's the finish line?
  • Is there a test suite I can add to, assuming that's important for my team?
  • How will it be deployed and tested?

Estimate

Estimating.. that's what this is all about. Hard to estimate if you don't even know what the work involves. But after you break things down into smaller pieces, slap some times on them.

  • If you have to request a change from the database or IT teams, or someone else, how involved is that process usually? Is there usually some back-and-forth, trial-and-error? Once they get started, how long does it usually take to get what you need and verify that it's working?
  • If there's unfamiliar parts of the system to research, think about what those are. Will you need a couple hours to check out that API? A half-day (or several days) to understand some authentication mechanism you're tying into?
  • Have to create a new screen? How long did that take you last time? A day? Oh, and an API? Is that another day? A week?
  • If you don't know where the code should go, or aren't familiar with the testing framework, build in some time to learn about that too.
  • How long does deploying changes take? Is it a manual process or automatic? How likely is it that your QA team will find bugs, requiring some rework? That's a toughies - we're aiming for no bugs, right? - but the odds go up if the work is complicated.

Buffer

I don't have a formula for this or anything, but every time I think a project (at work or life in general) will take 2 hours, it takes 3. If I think it'll take all day, it'll almost definitely bleed into the next day.

I think multiplying whatever estimate you come up with by 1.5 isn't unreasonable. There's always unknowns and unwelcome surprises. And when you come up with that estimate, stick with it. That's every bit as tough as coming up with the estimate in the first place. It might not be pleasant news to share, but at least you can back it up. And maybe some of it will get offloaded onto someone else, or some of those oh-so-necessary requirements will suddenly become a lot more negotiable.

To look at it a different way...

If you have to get your car fixed, and they tell you it'll take a full week, that's unpleasant news. Maybe they call at the end of the week, and tell you they ran into xyz and need 2 more days to get another part and install it. A little aggravating, but you can plan around it.

But what if they told you it'd be done by the end of the day, then called you at 5p to tell it'll actually be done by the end of the next day? Then called the next day to tell it's gonna take one more day... and on and on, for a couple weeks?

Other things suffer because you can't work around it. You can't estimate how long you'll need that rental. You can't request a couple hours off work to pick up the car when it's ready. You'd lose all confidence they know what they're doing, and (if it goes on long enough) even start to worry that you're not gonna get the car back anytime soon.

Author

Grant Winney

I write when I've got something to share - a personal project, a solution to a difficult problem, or just an idea. We learn by doing and sharing. We've all got something to contribute.


Comments / Reactions