7 ms·

I strongly disagree with this. This is an approach to development that encourages an extremely limited and short term view on development that leads to low qual

I strongly disagree with this. This is an approach to development that encourages an extremely limited and short term view on development that leads to low quality software and unhappy developers. It's also only remotely possible with a certain type of software.

TameAntelope 5y ago
If this approach results in you taking limited and short term views of development, or low quality software with unhappy developers, you're doing it wrong. Breaking down work into small, day-or-two chunks is a team effort that the developers are doing together, alongside the customer (representative, usually).
- Trasmatta 5y ago
  Not all development fits nicely into day-or-two chunks. Forcing all your work to fit nicely into this type of mold is an arbitrary restriction that serves no real purpose except to check all the necessary scrum boxes, give the illusion of extra productivity, and allow for micro-management. It ends up being completely antithetical to thinking deeply and long term about the the code you're writing. I've worked on teams that run the full gamut here. Those that did scrum and enforced "an every task should be one or two days" did not ship more or higher quality software than those that didn't, and the development teams were consistently more stressed and less satisfied with their work.
  - TameAntelope 5y ago
    What do you think of the idea that providing finished work on an every-day-or-two cadence allows you to collect feedback from your customers in a way that keeps your work focused and relevant to their needs?
    - Trasmatta 5y ago
      You can gather plenty of useful feedback to keep your work focused and relevant on cadences other than one or two days. What kind of customer even wants to provide feedback that often? That sounds awful, not to mention being a poor user experience, where users are treated like beta testers, with half baked features constantly pushed out the door. This also ignores the fact that there is a huge amount of important work that is effectively invisible to the end user, but is absolutely crucial. The workflow you're suggesting disincentives the team from working on those things, and may even punish them for it (as they are not shipping customer visible features).
      - TameAntelope 5y ago
        There is no such thing as work that's absolutely crucial and not customer facing, so it makes perfect sense to disincentivize work that's shaped as you describe. And before you try to list off work you think fits this category, I urge you to think about how that work could affect a customer's experience.
        Trasmatta 5y ago
        I didn't say "not costumer facing", I said "invisible". A lot of important work is something a customer will have no idea exists until it goes wrong. If you've done your job right, it will remain invisible forever. Because it's invisible, what's the point of arbitrarily shipping it in one-to-two day chunks to "gather user feedback"? Be willing to take the time to do hard things right. I'm not proposing you spin your wheels for ages on something, and I'm generally in favor of shipping early and often, it's just trying to fit every different shaped problem into the same process that doesn't work for me.
        TameAntelope 5y ago
        If it impacts a user negatively if it's done wrong, that sounds pretty damn visible to me. I can think of plenty of ways to show a customer how we fail gracefully or not at all despite certain negative events. Some customers may even value that very highly, depending on the use case. And I get that this idea may not work for you, but it works for a lot of very successful people, the luminaries of our field. You're arguing against Ward Cunningham, Robert C. Martin, James Shore, Martin Fowler, Joel Spolsky, Jeff Atwood, Bill Wake, Andrew Hunt, Dave Thomas, et. al. Customer collaboration over contract negotiation. [0] Who should I listen to; you, or them? [0] https://agilemanifesto.org/ https://agilemanifesto.org/
    - spc476 5y ago
      We asked our customer to include a small piece of information for every request they made to us to better serve them. It took five years for our customer to make the change. A one-or-two day cadence didn't make sense for us, nor apparently, for our customer. Oh, our customer? It's the Oligarchic Cell Phone Company. They don't move fast. And as a result, neither do we.
- anonymoushn 5y ago
  let's have a meeting about how to break down our investigation of the unexplained segfaults in nginx that occasionally happen in our cdn into chunks that deliver value daily!
  - Trasmatta 5y ago
    And then let's have daily progress meetings to report on the status of each chunk of the investigation! Please update Jira at least once a day! This is a great example of the perverse incentives built into the "everything should be done in one day chunks that you report on daily". The team is incentivized to ignore highly important but challenging / hidden work, and instead only focus on things that are highly visible to management.
    - vinaypunwani 5y ago
      I think the point is that the only work that matters is work that will improve the customer experience in some way. That could be infrastructure/stability work, or that could be visible front-end work. Not sure how you're using the word "hidden", but that's my reading from this discussion. Either of those things are important/valued by management probably. But none of that should imply or require micromanagement in a high-trust engineering org.
  - nitrogen 5y ago
    This is really not that hard: "Yesterday I looked for correlations between segfaults and hardware vendors. I did not find a correlation, and my deliverable for the day is narrowing the search space. Today I will set up a micro cluster of random traffic to try to reproduce the crash. Tomorrow I will look for patterns in request bodies and stack traces."
    - sunny3 5y ago
      Seriously, I feel you should write a blog post about this types of reporting strategies that describe the work that are both accurate and palatable to management (and perhaps most importantly avoid despise from other developers).
strictfp 5y ago
Yes. And additionally, you're going to be context-switched constantly by people wanting to show off their days work. No thank you.

TameAntelope 5y ago

If this approach results in you taking limited and short term views of development, or low quality software with unhappy developers, you're doing it wrong. Breaking down work into small, day-or-two chunks is a team effort that the developers are doing together, alongside the customer (representative, usually).

Trasmatta 5y ago
Not all development fits nicely into day-or-two chunks. Forcing all your work to fit nicely into this type of mold is an arbitrary restriction that serves no real purpose except to check all the necessary scrum boxes, give the illusion of extra productivity, and allow for micro-management. It ends up being completely antithetical to thinking deeply and long term about the the code you're writing. I've worked on teams that run the full gamut here. Those that did scrum and enforced "an every task should be one or two days" did not ship more or higher quality software than those that didn't, and the development teams were consistently more stressed and less satisfied with their work.
- TameAntelope 5y ago
  What do you think of the idea that providing finished work on an every-day-or-two cadence allows you to collect feedback from your customers in a way that keeps your work focused and relevant to their needs?
  - Trasmatta 5y ago
    You can gather plenty of useful feedback to keep your work focused and relevant on cadences other than one or two days. What kind of customer even wants to provide feedback that often? That sounds awful, not to mention being a poor user experience, where users are treated like beta testers, with half baked features constantly pushed out the door. This also ignores the fact that there is a huge amount of important work that is effectively invisible to the end user, but is absolutely crucial. The workflow you're suggesting disincentives the team from working on those things, and may even punish them for it (as they are not shipping customer visible features).
    - TameAntelope 5y ago
      There is no such thing as work that's absolutely crucial and not customer facing, so it makes perfect sense to disincentivize work that's shaped as you describe. And before you try to list off work you think fits this category, I urge you to think about how that work could affect a customer's experience.
      - Trasmatta 5y ago
        I didn't say "not costumer facing", I said "invisible". A lot of important work is something a customer will have no idea exists until it goes wrong. If you've done your job right, it will remain invisible forever. Because it's invisible, what's the point of arbitrarily shipping it in one-to-two day chunks to "gather user feedback"? Be willing to take the time to do hard things right. I'm not proposing you spin your wheels for ages on something, and I'm generally in favor of shipping early and often, it's just trying to fit every different shaped problem into the same process that doesn't work for me.
        TameAntelope 5y ago
        If it impacts a user negatively if it's done wrong, that sounds pretty damn visible to me. I can think of plenty of ways to show a customer how we fail gracefully or not at all despite certain negative events. Some customers may even value that very highly, depending on the use case. And I get that this idea may not work for you, but it works for a lot of very successful people, the luminaries of our field. You're arguing against Ward Cunningham, Robert C. Martin, James Shore, Martin Fowler, Joel Spolsky, Jeff Atwood, Bill Wake, Andrew Hunt, Dave Thomas, et. al. Customer collaboration over contract negotiation. [0] Who should I listen to; you, or them? [0] https://agilemanifesto.org/ https://agilemanifesto.org/
  - spc476 5y ago
    We asked our customer to include a small piece of information for every request they made to us to better serve them. It took five years for our customer to make the change. A one-or-two day cadence didn't make sense for us, nor apparently, for our customer. Oh, our customer? It's the Oligarchic Cell Phone Company. They don't move fast. And as a result, neither do we.
anonymoushn 5y ago
let's have a meeting about how to break down our investigation of the unexplained segfaults in nginx that occasionally happen in our cdn into chunks that deliver value daily!
- Trasmatta 5y ago
  And then let's have daily progress meetings to report on the status of each chunk of the investigation! Please update Jira at least once a day! This is a great example of the perverse incentives built into the "everything should be done in one day chunks that you report on daily". The team is incentivized to ignore highly important but challenging / hidden work, and instead only focus on things that are highly visible to management.
  - vinaypunwani 5y ago
    I think the point is that the only work that matters is work that will improve the customer experience in some way. That could be infrastructure/stability work, or that could be visible front-end work. Not sure how you're using the word "hidden", but that's my reading from this discussion. Either of those things are important/valued by management probably. But none of that should imply or require micromanagement in a high-trust engineering org.
- nitrogen 5y ago
  This is really not that hard: "Yesterday I looked for correlations between segfaults and hardware vendors. I did not find a correlation, and my deliverable for the day is narrowing the search space. Today I will set up a micro cluster of random traffic to try to reproduce the crash. Tomorrow I will look for patterns in request bodies and stack traces."
  - sunny3 5y ago
    Seriously, I feel you should write a blog post about this types of reporting strategies that describe the work that are both accurate and palatable to management (and perhaps most importantly avoid despise from other developers).

strictfp 5y ago

Yes. And additionally, you're going to be context-switched constantly by people wanting to show off their days work. No thank you.