Hacker Newsnew | past | comments | ask | show | jobs | submitlogin

I always see timeboxing as ensuring that an exploratory task does not blow up in terms of time spent on it.

This means you'll hear something like: "I'll timebox improving performance of this feature to a single day; it would be nice if we can get a quick win, but it's not really blocking if we do not.".

Maybe within 10 minutes of profiling you see that one line of code that is copying large data structures around unnecessarily and a quick refactor speeds the feature up 5x. Or maybe you spent all day on it and haven't found anything that's quick to fix: You fix up a couple of small inefficiencies and speed up the feature by 2%. You write down your findings and at least now the team will know that optimising that feature will be a larger undertaking and should be estimated as such.

I have also done it for very edge case bugs where no one is really sure what the cause is and fixing it is not high priority. You might get lucky and work it/fix it quickly; but if you don't, then at least you're not spending a week when the remaining 4 days could've been spent on something of higher priority.



Guidelines | FAQ | Lists | API | Security | Legal | Apply to YC | Contact

Search: