5 ms·

We tried this in a team a few years ago, and the problem we faced was developers literally falling asleep during readings. We found that the Team wasn't really

We tried this in a team a few years ago, and the problem we faced was developers literally falling asleep during readings. We found that the Team wasn't really engaging with the process and instead just tuned out until it was their turn. That doesn't mean I think Crockford's "Dailies" model is a poor one, it's just one issue to be aware of. Though I often find the same in Scrum teams. Folks aren't listening, they're just waiting for their turn to speak.

deleted 4y ago
[deleted]
the_other 4y ago
Sounds like a problem with the team more with the process. If they don't care, they wont care.
- tmp_anon_22 4y ago
  > If they don't care, they wont care. We need to accommodate human nature, not change human nature to accommodate corporate requirements. Its irrational to expect a group to rally passionately around every available task. Robotic.
  - mathgladiator 4y ago
    The good question is how to hire people that will care, and whether or not it can be incorporated into a culture.
    - ipaddr 4y ago
      Let's hire people good at programming and let's leave the fluff behind.
      - mathgladiator 4y ago
        After many years, defining "good at programming" is hard. I would say, reading your code is part of that. I used to read all the code that got checked-in for one of my large projects. The other part is that you can also grow people into being good. This is one of the more important roles of big-tech where college grads come in as n00bs and become engineers.
rvense 4y ago
This has been common in the scrum ceremonies I've participated in in most of my career. The standup is primarily for keeping your manager up to date on how things are going with your estimates and maybe for asking for help from a coworker with a blocking issue. I think what Crockford outlines here would be fantastic if it worked. Multiparty code review.
- pavlov 4y ago
  The reason it works for movie production teams is that they don’t watch dailies most working days of their career. The film shoot is a special high-intensity time. You may spend months and months in pre-production, but the actual shoot might only be 20-30 days (on a lower-end production). Every day needs to count. If you can learn from the previous day and improve, it makes a real difference near the end of the shoot when you’ll have much more freedom to experiment. In contrast, software engineering is more of a uniform slog. Back when software shipped in physical boxes, there used to be a marked difference between the planning, development and testing phases, but that’s gone. At many companies it’s just a grind of tiny features and endless tickets. Hard to get excited about the “dailies” for that.
  - corrral 4y ago
    Plus, if you miss a mistake in a shoot it will be expensive to fix after shooting wraps, if not impossible. Bugs might get more expensive to fix over time, but most don't, really. Not like that—not with such a very-near-future cliff after which they get far more expensive. And I'm not sure how many more you'd catch doing daily team reviews versus less-frequent targeted code reviews, anyway. The practice sure sounds brain-meltingly dull, to me, and with little benefit.
- TheBigSalad 4y ago
  If it feels that way I think your scrum master or entire team is doing a poor job. It shouldn't feel that way if you want it to work.
  - crooked-v 4y ago
WorldMaker 4y ago
> literally falling asleep during readings Dailies in film is watching not quite the final product, but still an output of the process. Maybe the issue was reading code as a team (that's code review/PR) rather than reviewing the output of the code? I think Dailies as a metaphor to me sounds like a call for more regular QA/UAT style review sessions as team. (This metaphor is new to me, but regular "use the product as a team" sessions might be quite useful, just maybe not every day.)
- mikehall314 4y ago
  Though he doesn't mention it in this video, I have seen Crockford promoting the 'Dailies' idea in talks before - and he does promote it as a replacement for code review and stand up. One hour, every morning, where the entire Team reads the code written the previous day and offers feedback. Juniors learn from seeing real-world code presented and explained, Seniors get peer review, more eyes means fewer bugs, etc. It didn't work for my Team, but I would be interested in trying it again in future.
tomcam 4y ago
> Folks aren't listening, they're just waiting for their turn to speak. That statement works in so many contexts

deleted 4y ago

[deleted]

the_other 4y ago

Sounds like a problem with the team more with the process. If they don't care, they wont care.

tmp_anon_22 4y ago
> If they don't care, they wont care. We need to accommodate human nature, not change human nature to accommodate corporate requirements. Its irrational to expect a group to rally passionately around every available task. Robotic.
- mathgladiator 4y ago
  The good question is how to hire people that will care, and whether or not it can be incorporated into a culture.
  - ipaddr 4y ago
    Let's hire people good at programming and let's leave the fluff behind.
    - mathgladiator 4y ago
      After many years, defining "good at programming" is hard. I would say, reading your code is part of that. I used to read all the code that got checked-in for one of my large projects. The other part is that you can also grow people into being good. This is one of the more important roles of big-tech where college grads come in as n00bs and become engineers.

rvense 4y ago

This has been common in the scrum ceremonies I've participated in in most of my career. The standup is primarily for keeping your manager up to date on how things are going with your estimates and maybe for asking for help from a coworker with a blocking issue. I think what Crockford outlines here would be fantastic if it worked. Multiparty code review.

pavlov 4y ago
The reason it works for movie production teams is that they don’t watch dailies most working days of their career. The film shoot is a special high-intensity time. You may spend months and months in pre-production, but the actual shoot might only be 20-30 days (on a lower-end production). Every day needs to count. If you can learn from the previous day and improve, it makes a real difference near the end of the shoot when you’ll have much more freedom to experiment. In contrast, software engineering is more of a uniform slog. Back when software shipped in physical boxes, there used to be a marked difference between the planning, development and testing phases, but that’s gone. At many companies it’s just a grind of tiny features and endless tickets. Hard to get excited about the “dailies” for that.
- corrral 4y ago
  Plus, if you miss a mistake in a shoot it will be expensive to fix after shooting wraps, if not impossible. Bugs might get more expensive to fix over time, but most don't, really. Not like that—not with such a very-near-future cliff after which they get far more expensive. And I'm not sure how many more you'd catch doing daily team reviews versus less-frequent targeted code reviews, anyway. The practice sure sounds brain-meltingly dull, to me, and with little benefit.
TheBigSalad 4y ago
If it feels that way I think your scrum master or entire team is doing a poor job. It shouldn't feel that way if you want it to work.
- crooked-v 4y ago

WorldMaker 4y ago

> literally falling asleep during readings Dailies in film is watching not quite the final product, but still an output of the process. Maybe the issue was reading code as a team (that's code review/PR) rather than reviewing the output of the code? I think Dailies as a metaphor to me sounds like a call for more regular QA/UAT style review sessions as team. (This metaphor is new to me, but regular "use the product as a team" sessions might be quite useful, just maybe not every day.)

mikehall314 4y ago
Though he doesn't mention it in this video, I have seen Crockford promoting the 'Dailies' idea in talks before - and he does promote it as a replacement for code review and stand up. One hour, every morning, where the entire Team reads the code written the previous day and offers feedback. Juniors learn from seeing real-world code presented and explained, Seniors get peer review, more eyes means fewer bugs, etc. It didn't work for my Team, but I would be interested in trying it again in future.

tomcam 4y ago

> Folks aren't listening, they're just waiting for their turn to speak. That statement works in so many contexts