Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

An epic treatise on scheduling, bug tracking, and triage

apenwarr.ca

Post reply on HN
Print view View original

61–67 of 67 posts

Re: An epic treatise on scheduling, bug tracking, and triage

#61

Post by gingerlime »

apenwarr wrote: post #6

I’m the author of the article. I apologize for its massive length but wasn’t able to make it shorter without losing my favourite bits :) I’m happy to answer any questions people have here.

Amazing stuff. It was a real pleasure to read. Despite its length I couldn't get myself to skip ahead or skim.

We're now in the process of switching to a structure similar to Basecamp's 6-week cycles[0]. And those cycles obviously do have a deadline. However, I would still say this kind of deadline is better than your typical one for a couple of reasons:

1. The team is self-managing. Typically the team was involved in the pitch process for the project, so they have vested interest in getting this done. I think this is key to avoiding the Student problem. It's no longer an assignment dropped from above, but something you are keen to push forward.

2. The cycle is 6 weeks rather than a sprint of 2... So this feels more like a slower-pace mini-marathon. And the team has autonomy to drop features or make adjustments. I admit that's a weaker argument for it than the one above.

I wonder what's your take on this?

[0] https://m.signalvnoise.com/how-we-set-up-our-work-cbce3d3d9c...

Re: An epic treatise on scheduling, bug tracking, and triage

#62

Post by po »

apenwarr wrote: post #29
jasode wrote: post #15

Earlier quoted context omitted.

>its massive length but wasn’t able to make it shorter It's always possible to make it shorter to help communicate a main idea . (However, it does takes extra effort to extract the essence of a long piece.[1]) Your essay is ~15,000 words and desperately needs a short "elevator pitch" of its main points. I'm a very verbose writer so when I think others' writing is verbose, it means everybody is going to drown in the t…

I know what you mean, and in general I try to follow that advice. In the particular case of project management though, I'm frustrated by the huge amount of too-short and contradictory advice floating around on the Internet; adding one more unjustified summary to the pile doesn't help. So I think the extra details are important. And when you have that many details, the tangential expository fluff helps keep it interes…

FWIW, I liked this format. It reads like a presentation and digresses and regroups back to the main thread throughout. It may make it less widely read but I think it may also make it more memorable and loved.

The value for the reader is in the act of chewing over a familiar problem along with your guidance. If the main points were made more obvious, then perhaps it also becomes more boring.

If you want to propose a more tangible recommendation/guide/process then yeah, give people hooky, easy to remember bits.

Re: An epic treatise on scheduling, bug tracking, and triage

#63

Post by naasking »

ndh2 wrote: post #41
jasode wrote: post #40

Earlier quoted context omitted.

>So I think the extra details are important. [...] This is also why I didn't summarize everything at the top: that would encourage people to just read the top and stop there. There's an opposite way to look at it: a good summary acts as a "hook" and entices readers to read the rest of 15000 words. I wasn't suggesting you delete the extra details. Instead, the bullet points at the top give the reader a "road map" to t…

I agree. This is the internet, after all. The first question is: Is this worth my time and attention?

I decided it was worth my time and attention because the HN comments were mostly positive. Once I skipped the personal intro, the argument was sufficiently engaging to keep me going.

I think the author is partly right that a breakdown might be more harmful because you lose too much information. HN and reddit comments are how I decide whether something is worth my time, so a summary isn't necessarily beneficial.

Re: An epic treatise on scheduling, bug tracking, and triage

#64

Post by naasking »

voxl wrote: post #30
apenwarr wrote: post #6

I’m the author of the article. I apologize for its massive length but wasn’t able to make it shorter without losing my favourite bits :) I’m happy to answer any questions people have here.

I disagree strongly with your take on story points: First, if story points are an indirect measure of time, then the "psychological game" you're playing will be immediately revealed if your engineers are as smart as claimed. There is no reason for me to point something a 2 over a 3 unless you're measuring the time it takes to deliver software based off those measurements. On the opposite end of the spectrum, my confi…

> First, if story points are an indirect measure of time, then the "psychological game" you're playing will be immediately revealed if your engineers are as smart as claimed.

Adding a level of indirection removes some implicit biases. Points might be indirectly related to time, but only incidentally. Points sound more directly related to task complexity, which is itself indirectly related to time.

It's kind of like how lines of code seems like kind of a poor measure of program complexity, and yet, study after study has shown that regardless of language, framework, etc. the number of line of code is the best measure we have for latent bug count. This correlation doesn't always make sense if you look at specific, contrived examples, but the property seems to hold in aggregate.

Re: An epic treatise on scheduling, bug tracking, and triage

#65

Post by naasking »

voxl wrote: post #44
apenwarr wrote: post #42

Earlier quoted context omitted.

If you look at the first Central Limit Theorem slide in the original article, it compares story precision vs precision of unestimated bugs. The short answer is that if your stories are big, not estimating them causes more error (weeks or months) than most people are willing to accept. Not so with small tasks (bugs) which average out, as you suggest. However, it’s hard to make long-range estimates using only many tiny…

Except you can't, as I've said, engineers are not good at estimating. They get significantly worse when you start estimating months out instead of days out. The problem is not that they're engineers, no one is good at estimating work they've never done before. This is a well known problem in pretty much every single software shop I've ever been in. Teams never deliver what was planned on time, only functional teams c…

> Except you can't, as I've said, engineers are not good at estimating. They get significantly worse when you start estimating months out instead of days out.

Because you keep focusing on time estimates instead of point estimates. People have intrinsic biases related to time and their productivity. Like how most people implicitly assume they're above average in intelligence, looks, etc.

Re: An epic treatise on scheduling, bug tracking, and triage

#66

Post by Joeri »

apenwarr wrote: post #6

I’m the author of the article. I apologize for its massive length but wasn’t able to make it shorter without losing my favourite bits :) I’m happy to answer any questions people have here.

I thought this was very insightful and spot on for the most part, but I had one remark.

I object to the notion that it’s ok for bug ingress rate to be higher than bug egress. For me that’s symptomatic of underlying problems. Either (A) those bugs are on important features, and the team is favoring novelty over functionality by prioritizing new feature dev over feature maintenance, or (B) the broken features are unimportant and the team is failing to weed out irrelevant functionality from their codebase (it is important to remove features while you add them to not get in a zero-progress situation, unless you grow the team along with the codebase), or (C) the team has bad engineering practices causing a high ingress rate, or (D) many bugs are based on misunderstandings, which points to documentation or UX issues. No matter how you slice it, I see it as never acceptable to let a bug pile grow indefinitely.

Do you see this as a sort of compromise, as in it indeed pointing to deeper problems but needing a workaround in the real world, or do you disagree that a growing bug pile is symptomatic of deeper problems?

Re: An epic treatise on scheduling, bug tracking, and triage

#67

Post by lliamander »

markphip wrote: post #57
lliamander wrote: post #54

Earlier quoted context omitted.

I actually reject the idea of story points as a unit-less number, mostly because people can't help but think about them in terms of time anyway (whether they want to or not) [1]. Rather, I like to use a discrete list of story point values as scalar value that represents a probability distribution for how long the task might take. As the story point gets bigger, not only does the mean time get bigger, but the variance…

Thanks and interesting. If you have written up your full system anywhere I would be interested to read more.

In terms of mapping story points to time ranges, here's the full list:

1 point -> 2-4 hours

2 points -> 4-8 hours (1 day or less)

3 points -> 1-2 days

5 points -> 3-5 days (up to one week)

8 points -> 5-9 days (up to one two-week sprint[0])

13 points -> 2-3 weeks (1-1.5 sprints)

20 points -> 3-4 weeks (up to two sprints)

40 points -> 1-2 months

Anything beyond 40 needs to be aggressively analyzed broken down into steps, even if those steps are not deliverable features per se.

[0]For a two-week sprint, you have to account for at least one day each sprint for demos, retrospective, and planning. Thus, you have at most 9 days for implementation and testing.

EDIT: Fixed formatting.

Post reply on HN