Skip to content
 

“5 minutes? Really?”

Bob writes:

Daniel says this issue

https://github.com/stan-dev/stan/issues/795#issuecomment-26390557117

is an easy 5-minute fix.

In my ongoing role as wet blanket, let’s be realistic. It’s
sort of like saying it’s an hour from here to Detroit because
that’s how long the plane’s in the air.

Nothing is a 5 minute fix (door to door) for Stan and I really
don’t want to give people the impression that it should be. It
then just makes them feel bad when it takes longer than 5 minutes,
because they feel like they’ve wasted the time this will really take.
Or it makes people angry who suggest other “5 minute fixes” that
we don’t get around to doing because they’re really more involved.

This can’t be five minutes (certainly not net to the project)
when you need to create a branch, fix the issue, run the tests,
run cpplint, commit, push, create a pull request,
nag someone else to review it (then they have to then fill out the
code-review form), then you might have to make fixes (and perhaps
get another sign off from the reviewer), then Jenkins and Travis
may need to be kicked, (then someone has to decide to merge),
then we get to do it again in the upstream with changes to
the interfaces.

Easy once you’re used to the process, but not 5 minutes!

The mythical man-minute.

3 Comments

  1. With all of that overhead, it may make sense to batch up a bunch of the “simpler” fixes, do a really careful job of documenting a combined effort, and check them all in at once, running through the test suite etc as a batch. If that means more small fixes get done, then it’s probably a good idea, though of course it does make the history a little more complicated…

  2. zbicyclist says:

    Many years ago I heard a rule of thumb about software projects.

    Take the time estimate, double it, and move to the next higher unit of measurement.

    So, a 5 minute fix should be expected to take 10 hours elapsed time.

    I’ve found this rule of thumb to be fairly accurate, if slightly pessimistic – part of this is due to the fact that other stuff (e.g. production fixes, what the CEO suddenly wants, etc.) intervene and get higher priority.

Leave a Reply