An epic treatise on scheduling, bug tracking, and triage • Hacker News Board

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

#21

Post by jasode » Thu, Dec 14, 2017, 4:06 PM UTC

agentultra wrote: post #18

pjc50 wrote: post #8

Earlier quoted context omitted.

So .. what is the business substitute for deadlines? Unless you're genuinely a startup with unlimited funding and total freedom, eventually people are going to ask the question "so what are you going to deliver and when?"

That is often the first question I get asked when trying to explain these concepts to business owners. My answer is that you can plan for work to be done on a deadline but you can't negotiate when it will be done with the people doing the work. It's going to take as long as it takes. It's poor management that sets unrealistic expectations and demands results. You can plan for work by using data. You get data by track…

>It's going to take as long as it takes. [...] it may not be the whole kit

If I'm interpreting that fragment right, your essay is treating "programmers development time" as a fixed rate of progress (the "9 women can't have a baby in 1 month" meme) so one answer to meet a deadline is to remove features until the deadline can be met.

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

#22

Post by platform » Thu, Dec 14, 2017, 4:08 PM UTC

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.

Agile is meant to be used for non-software delivery projects as well.

In your view, with the parts you crossed out (including the physiological/motivational structures)-- would Agile still be widely applicable outside of the software-oriented projects?

Couple of, say, hypothetical examples, perhaps for non-software projects

-- developing & submitting scientific grant application

-- organizing a non-trivial longitudinal survey

-- looking for college for kids

-- designing a motorcycle with unique frame/engine layout

-- planning and shooting a movie

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

#23

Post by systematical » Thu, Dec 14, 2017, 4:17 PM UTC

jasode wrote: post #15

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.

>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…

TL;DR thanks. ++good writing advice

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

#24

Post by falsedan » Thu, Dec 14, 2017, 4:19 PM UTC

apenwarr wrote: post #14

falsedan wrote: post #12

Earlier quoted context omitted.

I don't understand. A summary should summarise. An explanation should explain, an argument should convince, a historical overview should retell events. Obviously, a summary can't be an explanation + an argument + history. It has to be the most salient points presented alone . Think about an abstract for a paper: it should tell you enough that you can understand if you should read the paper now, and enough context so…

I quite liked the tl;dr, except that it left out how most of the article is "...and why". We've all heard the advice, but the article is trying to explain why the advice is true. I think an ideal summary would mention that.

OK, I understand. Though I think the article did a terrible job of explaining why: like, why do deadlines cause engineers to become affected by Student Syndrome? It just mentions it at a superficial level, which is perfectly fine for its purposes.

edit: also thanks for writing that article, it's great.

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

#25

Post by apenwarr » Thu, Dec 14, 2017, 4:24 PM UTC

peterwwillis wrote: post #16

> What doesn't work is deciding when you're going to get there. That would be an ETA, which is quite useful in many cases. > Or telling salespeople they need to sell 10% more next quarter. That's a minimum quota. Also useful. > Or telling school teachers they need to improve their standardized test scores. Which is not so much a 'goal' as it is a response to the need for kids to actually learn information. It's a goa…

What all these wrong-goal examples have in common is that people have tried them over and over, and they never work the way you want. The reason they never work is that they don't specify the method. As one of my favourite Deming quotes says, "If you can accomplish a [numerical quality/goal] goal without a [new] method, then why were you not doing it last year? There is only one possible answer: you were goofing off."

What ends up happening is that people will cheat the system so they can hit the target you enforced, while sacrificing some other critical thing you forgot to enforce. In the educational system, for example, what happens is "teach to the test," which causes improved standardized test scores at the expense of actually learning things. And, of course, you get schools that outright cheat when scoring the tests: https://www.washingtonpost.com/news/answer-sheet/wp/2015/04/...

Re: ETAs, those are predictions, not goals. Predictions are good. Most of the article is about the difference between the two.

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

#26

Post by apenwarr » Thu, Dec 14, 2017, 4:27 PM UTC

ndh2 wrote: post #19

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.

First, thank you very much for the write-up, I sure found it interesting as well as entertaining. When using bug trackers, I find the most frustrating aspect is the "non-linearity" of the workflow. By that I mean, how do I answer the question "What am I supposed to do next?". You can sort by project, or by priority, but what I typically end up with is a list of items that I already looked at a dozen times. And even t…

The way I like to do it is to keep multiple backlogs, broken down roughly by feature group (ie. groups of things that might eventually become a milestone or story of their own). Then when I decide to prioritize a given story, I can go to the relevant backlog and re-triage only the bugs in there, which should hopefully be a relatively manageable number.

Another benefit of sub-categorizing this way is that it makes it easier to resolve bugs as duplicates. When a new bug is filed, it's hard to see that it's a duplicate when you're comparing it against 10000 other bugs, but it's easier when you're comparing it against only 100 other bugs in the same category.

I doubt you'll ever be able to get it down to "at most twice." But it needs to be much easier than ever resotring to "looking through the whole list."

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

#27

Post by apenwarr » Thu, Dec 14, 2017, 4:30 PM UTC

platform wrote: post #22

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.

Agile is meant to be used for non-software delivery projects as well. In your view, with the parts you crossed out (including the physiological/motivational structures)-- would Agile still be widely applicable outside of the software-oriented projects? Couple of, say, hypothetical examples, perhaps for non-software projects -- developing & submitting scientific grant application -- organizing a non-trivial longitudin…

In my opinion (and you should take it as an opinion :)), the "good parts" of Agile are the same for both software and non-software projects. Estimation, strict prioritization, and (automated) progress tracking are the keys to any successful project management.

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

#28

Post by bvrmn » Thu, Dec 14, 2017, 4:38 PM UTC

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.

Wonderful article, read it like a blockbuster with a constants clicking in my brain. Every time I tried to impose some sort of sprints for myself and the team it always end in Friday superdense coding with a half task moving to the next sprint. Thank you for a great argumentation why precise estimation is a bullshit bingo, I tried to show to PM's that only a steepness of slope is important and managers can plan work without exact dev-hours, but without much success, your explanation is clear and easy to understand.

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

#29

Post by apenwarr » Thu, Dec 14, 2017, 4:40 PM UTC

jasode wrote: post #15

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.

>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 interesting. I hope.

This is also why I didn't summarize everything at the top: that would encourage people to just read the top and stop there. They can do that with project management advice anywhere on the Internet. There's a place for that, but there's plenty of it already.

At least it's shorter than a book. :)

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

#30

Post by voxl » Thu, Dec 14, 2017, 4:48 PM UTC

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 confidence in whether a story is an 8 or a 13 becomes significantly weaker as the numbers get bigger.

Using numbers, specifically, is a hint that whomever is handling process just wants to predict when the project will be done. Numbers trick you into thinking they can be added, margins of error are not additive. My go-to question in these situations is why don't we just estimate with abstract sizes? (Small, Medium, Large, etc) Surprisingly I'm often met with resistance.

Second, if story points are not an indirect measure of time, then why are you pointing stories? What does the pointing gain your team other than fluff? If you say it's for prioritization then you're just invalidating the premise and we're back to an indirect measure of time.

Finally, I have not seen, and you have not presented, evidence that engineers are good at estimating. In fact all that I have read seems to indicate the exact opposite, that engineers are very bad at estimating (in fact that they are largely too optimistic). One could argue that this can be trained, or that you'll get better at estimating as you gain more experience. Which I will concede that you will get faster and better at estimating and implementing the same exact feature, but that is not what we do. We implement new features, things we likely haven't done before.