4 ms·

An epic treatise on scheduling, bug tracking, and triage (2017)

66 points by kiyanwang 5y ago

ExtraE 5y ago
https://news.ycombinator.com/item?id=15912929 https://news.ycombinator.com/item?id=15912929
- dang 5y ago
  Thanks! Macroexpanded: An epic treatise on scheduling, bug tracking, and triage - https://news.ycombinator.com/item?id=15912929 https://news.ycombinator.com/item?id=15912929 - Dec 2017 (65 comments)
FeepingCreature 5y ago
Good post, but I just wanna jump on one tiny point of this out of context and say that pair programming (if done cleanly) is actually amazing for skill transfer.
- agent327 5y ago
  I'll jump on this completely out of context and say that if I'm ever forced to work with another human being permanently glued to my side, watching my every move, and requiring constant maintenance in terms of explanation and synchronized breaks, I'll happily resign on the spot. Programming is an intensely internal task, usually performed by introverted people. Forcing them into this kind of setup should be counted as torture. Before you disagree, consider how many other professions have pair-working in any shape or form. Is there any pair-management going on? How about pair-assembly line working? Yes, multiple people work on an assembly line - but they are performing different tasks, not just checking up on each other in real time, 8 hours per day! People work in teams, I get that, and it requires interaction between team members. But name me one team where there are two people permanently assigned to literally the same task, with no goals other than 'improving efficiency'. It's just amazing that anyone would put up with that.
  - FeepingCreature 5y ago
    Oh no, permanent pair programming is insanity, it's just really effective for onboarding. I assume assembly line workers also pair work while the new worker is getting up to speed. At any rate, the more you're working in a large team, the less your programming should be "an intensely personal task". We have style guides for a reason...
    - zeisss 5y ago
      +1 for doing this for onboarding / knowledge sharing or just brainstorming possible solutions to a problem. But do it with a clear timebox (maybe 1-2h) and breaks in between. Having to do this longer (like a whole day, even with breaks etc) would drive me nuts as well. Sometimes I just need to stare at the code for a while or draw pretty boxes with arrows on a piece of paper (kind of hard to share in a remote setting).
      - FeepingCreature 5y ago
        Yeah definitely.
    - agent327 5y ago
      I said "intensely internal", not "intensely personal". If you think the only thing that programmers do is typing out code without any thought, you have very badly misunderstood the profession.
      - FeepingCreature 5y ago
        Sorry, I misread you. Yeah it's strongly a matter of time and place, but in the right time and place, pairing can be excellent.
cpach 5y ago
Avery inspired me to buy one of Deming’s books. Alas, I haven’t read it yet, but this was a good reminder that I should do so. (IIRC the one I bought was The New Economics for Industry, Government, Education.)
- Tomte 5y ago
  My summary of the book: https://www.2uo.de/deming/ https://www.2uo.de/deming/
- kqr 5y ago
  Reading Deming prompted some fundamental changes in how I approach many different things in life. I strongly recommend taking the time.
hamilyon2 5y ago
I would very much like this line of thought, but elaborated even more. Maybe with real science thrown in. Can anyone recommend books, articles, about Demming's ideas tested empirically, about deadlines' influence, estimation psychology etc.?
- kqr 5y ago
  This kind of stuff is all I've been reading recently. I suggest the following, maybe possibly even in the order given. It's difficult to give a single recommendation, because it's a broad topic that branches off into several important directions. A continuously improving learning organisation takes many interlocking ideas to work, relating to long-term value powered culture, economic and probabilistic reasoning, uncertainty reduction techniques, including running experiments and gathering data on them, and analysing that data. But more important than running experiments are figuring out where the heck you stand and where you want to go. Just knowing that gets you halfway there. ---- These first four I would consider mandatory for anyone interested in this kind of stuff. - Out of the Crisis or The New Economics (I keep confusing these with each other because I read them after each other -- well, you've probably read these already given your comment) - The Machine That Changed the World (this seminal study introduced the industry to the idea of lean manufacturing, and it tells you exactly how important the ideas of lean/flow are) - Principles of Product Development Flow (the author is a guru in applying lean/flow ideas to product development and teaches you to not blindly apply lean manufacturing ideas to development, but to adapt them to the economic conditions of development) - Lean Product and Process Development (an opinionated but very intriguing view on how product development should be done, with focus on building a learning organisation) ---- These next ones are a little less mandatory and not necessarily extremely topical, but still interesting. - How To Measure Anything (before you collect data the most expensive way possible -- with experimentation -- try estimation using proper techniques first; it's really cheap and surprisingly good) - Understanding Variation (a good introduction to statistical process control, which helps you interpret your operational experience) - Learning To See (value stream mapping is a way to visualise some wastes in processes) - Accelerate (huge, impressive study of what high performing development organisations do differently) - Drive (primer on the psychology of motivation) - Trustworthy Online Controlled Experiments (there are probably better books on experimental design -- I've been eyeing some of Deming's myself -- but this one is probably as good a primer as any) - The Flaw of Averages (to get more accurate predictions, focus on distributions and ranges, not single numbers) - Toyota Kata (a rote way to build a culture of continuous improvement) - Making Software: What Really Works, and Why We Believe It (general high-quality exposition on evidence-backed techniques -- maybe not strictly in the scheduling/project management realm) - Rapid Development (like Making Software except older and thicker) - Turn the Ship Around (case study in applying some of these principles to completely change the performance of a team) - Lean Enterprise (more on how to adapt lean ideas to the whole development organisation, with case studies, IIRC) - Willful Ignorance (what are probabilistic statements, really?) ---- I have many more recommendations if you want to go deeper into a specific sub-topic, but this is probably enough for a cursory comment.
andrekandre 5y ago
> You can produce 20% more by hiring one more person for your 5-person team, and nobody even has to work overtime. Forget it. not to take away from the original point of the author, but unless a team/software/business is architected for scaling up-front, just adding another person rarely nets a linear increase in output, and sometimes actually reduces it

66 points by kiyanwang 5y ago

ExtraE 5y ago

https://news.ycombinator.com/item?id=15912929 https://news.ycombinator.com/item?id=15912929

dang 5y ago
Thanks! Macroexpanded: An epic treatise on scheduling, bug tracking, and triage - https://news.ycombinator.com/item?id=15912929 https://news.ycombinator.com/item?id=15912929 - Dec 2017 (65 comments)

FeepingCreature 5y ago

Good post, but I just wanna jump on one tiny point of this out of context and say that pair programming (if done cleanly) is actually amazing for skill transfer.

agent327 5y ago
I'll jump on this completely out of context and say that if I'm ever forced to work with another human being permanently glued to my side, watching my every move, and requiring constant maintenance in terms of explanation and synchronized breaks, I'll happily resign on the spot. Programming is an intensely internal task, usually performed by introverted people. Forcing them into this kind of setup should be counted as torture. Before you disagree, consider how many other professions have pair-working in any shape or form. Is there any pair-management going on? How about pair-assembly line working? Yes, multiple people work on an assembly line - but they are performing different tasks, not just checking up on each other in real time, 8 hours per day! People work in teams, I get that, and it requires interaction between team members. But name me one team where there are two people permanently assigned to literally the same task, with no goals other than 'improving efficiency'. It's just amazing that anyone would put up with that.
- FeepingCreature 5y ago
  Oh no, permanent pair programming is insanity, it's just really effective for onboarding. I assume assembly line workers also pair work while the new worker is getting up to speed. At any rate, the more you're working in a large team, the less your programming should be "an intensely personal task". We have style guides for a reason...
  - zeisss 5y ago
    +1 for doing this for onboarding / knowledge sharing or just brainstorming possible solutions to a problem. But do it with a clear timebox (maybe 1-2h) and breaks in between. Having to do this longer (like a whole day, even with breaks etc) would drive me nuts as well. Sometimes I just need to stare at the code for a while or draw pretty boxes with arrows on a piece of paper (kind of hard to share in a remote setting).
    - FeepingCreature 5y ago
      Yeah definitely.
  - agent327 5y ago
    I said "intensely internal", not "intensely personal". If you think the only thing that programmers do is typing out code without any thought, you have very badly misunderstood the profession.
    - FeepingCreature 5y ago
      Sorry, I misread you. Yeah it's strongly a matter of time and place, but in the right time and place, pairing can be excellent.

cpach 5y ago

Avery inspired me to buy one of Deming’s books. Alas, I haven’t read it yet, but this was a good reminder that I should do so. (IIRC the one I bought was The New Economics for Industry, Government, Education.)

Tomte 5y ago
My summary of the book: https://www.2uo.de/deming/ https://www.2uo.de/deming/
kqr 5y ago
Reading Deming prompted some fundamental changes in how I approach many different things in life. I strongly recommend taking the time.

hamilyon2 5y ago

I would very much like this line of thought, but elaborated even more. Maybe with real science thrown in. Can anyone recommend books, articles, about Demming's ideas tested empirically, about deadlines' influence, estimation psychology etc.?

kqr 5y ago
This kind of stuff is all I've been reading recently. I suggest the following, maybe possibly even in the order given. It's difficult to give a single recommendation, because it's a broad topic that branches off into several important directions. A continuously improving learning organisation takes many interlocking ideas to work, relating to long-term value powered culture, economic and probabilistic reasoning, uncertainty reduction techniques, including running experiments and gathering data on them, and analysing that data. But more important than running experiments are figuring out where the heck you stand and where you want to go. Just knowing that gets you halfway there. ---- These first four I would consider mandatory for anyone interested in this kind of stuff. - Out of the Crisis or The New Economics (I keep confusing these with each other because I read them after each other -- well, you've probably read these already given your comment) - The Machine That Changed the World (this seminal study introduced the industry to the idea of lean manufacturing, and it tells you exactly how important the ideas of lean/flow are) - Principles of Product Development Flow (the author is a guru in applying lean/flow ideas to product development and teaches you to not blindly apply lean manufacturing ideas to development, but to adapt them to the economic conditions of development) - Lean Product and Process Development (an opinionated but very intriguing view on how product development should be done, with focus on building a learning organisation) ---- These next ones are a little less mandatory and not necessarily extremely topical, but still interesting. - How To Measure Anything (before you collect data the most expensive way possible -- with experimentation -- try estimation using proper techniques first; it's really cheap and surprisingly good) - Understanding Variation (a good introduction to statistical process control, which helps you interpret your operational experience) - Learning To See (value stream mapping is a way to visualise some wastes in processes) - Accelerate (huge, impressive study of what high performing development organisations do differently) - Drive (primer on the psychology of motivation) - Trustworthy Online Controlled Experiments (there are probably better books on experimental design -- I've been eyeing some of Deming's myself -- but this one is probably as good a primer as any) - The Flaw of Averages (to get more accurate predictions, focus on distributions and ranges, not single numbers) - Toyota Kata (a rote way to build a culture of continuous improvement) - Making Software: What Really Works, and Why We Believe It (general high-quality exposition on evidence-backed techniques -- maybe not strictly in the scheduling/project management realm) - Rapid Development (like Making Software except older and thicker) - Turn the Ship Around (case study in applying some of these principles to completely change the performance of a team) - Lean Enterprise (more on how to adapt lean ideas to the whole development organisation, with case studies, IIRC) - Willful Ignorance (what are probabilistic statements, really?) ---- I have many more recommendations if you want to go deeper into a specific sub-topic, but this is probably enough for a cursory comment.

andrekandre 5y ago

> You can produce 20% more by hiring one more person for your 5-person team, and nobody even has to work overtime. Forget it. not to take away from the original point of the author, but unless a team/software/business is architected for scaling up-front, just adding another person rarely nets a linear increase in output, and sometimes actually reduces it