6 ms·

And I'd add that the need for them is a sign they aren't worth doing. As you say, worthwhile software is usually novel. And to justify our expense, it needs to

by wpietri 10mo ago

And I'd add that the need for them is a sign they aren't worth doing. As you say, worthwhile software is usually novel. And to justify our expense, it needs to be valuable. So to decide whether a project is worth doing, we're looking at some sort of estimate of return on investment. That estimate will also, at least implicitly, have a range. That range is determined by both the I and the R. If you don't have a precise estimate of return, making your estimate of investment more precise doesn't help anything. And I've never seen an estimate of return both precise and accurate; business is even less certain than software. In my opinion, effort put into careful estimates is almost always better put into early, iterative delivery and product management that maximizes the information gained. Shipping early and often buys much clearer information on both I and R than you can ever get in a conference room. Of course all of this only matters if running an effective business is more important than managerial soap opera and office politics. Those often require estimates in much the same way they're required from Star Trek's engineers: so the people with main character syndrome have something to dramatically ignore or override to prove their dominance over the NPCs and material reality.

bpt3 10mo ago
The solution you described is basically agile, and that definitely includes estimates and deadlines.
- Mtinie 10mo ago
  It’s Agile philosophically, and how it should be. But that is rarely how it works. In the dozens of different projects across ten or twelve companies I’ve had insight into, “doing Agile” is analogous with “we have a scrum master, hold stand ups, and schedule iterations” while the simple reality is “Agilefall.”
  - bpt3 10mo ago
    Agreed, but the parent poster said that estimates shouldn't be done at all, which is not a legitimate argument to make in any scenario.
    - collingreen 10mo ago
      I, and others, don't agree with the blanket statement that "no estimates" is not a legitimate argument in any scenario. Can you expand on why you think there isn't a single case where estimates don't add value? Similarly, is there anything specifically in that post's claims that you think was incorrect, leading to their false conclusion?
      - bpt3 10mo ago
        Okay, a scenario where you're building a hobby project alone and you don't care if or when it gets finished would be one where estimates aren't needed. There is no scenario where it's appropriate or necessary when developing software professionally or even as a side project where others are expecting you to complete work at some point. One of the many misconceptions in the original comment in this thread is that "worthwhile software is usually novel", which is not the case without a very specific and novel definition of worthwhile that I don't believe was intended.
        kragen 10mo ago
        If software isn't novel, that means some other, existing software does the same thing just as well in the same way on the same platform. So, unless it's a hobby project you're building alone, why don't you just use the existing software? I think that writing software that isn't novel fails to be worthwhile by a perfectly ordinary, mainstream definition of "worthwhile".
        bpt3 10mo ago
        So you would consider a CRUD app with some basic business rules to be novel? Basically meaning that any software that requires any development effort is novel? That's a completely valid definition of worthwhile software, but to claim it's impossible to create an estimate to complete said development is absurd.
        collingreen 10mo ago
- wild_egg 10mo ago
  I missed that part of the manifesto
  - wpietri 10mo ago
    Right? For those who want to check, the four values: https://agilemanifesto.org/ https://agilemanifesto.org/ And the 12 principles: https://agilemanifesto.org/principles.html https://agilemanifesto.org/principles.html But to my dismay, the Agile world quickly got colonized by certification schemes and consultants targeting large companies, so it rapidly turned into something that a lot of the early people were very disappointed with. I wrote about the dynamic some years back: https://williampietri.com/writing/2011/agiles-second-chasm-and-how-we-fell-in/ https://williampietri.com/writing/2011/agiles-second-chasm-a...
    - bpt3 10mo ago
      How do you do either of the following without spending any time at all on estimates? "Deliver working software frequently, from a couple of weeks to a couple of months, with a preference to the shorter timescale." "At regular intervals, the team reflects on how to become more effective, then tunes and adjusts its behavior accordingly." If I was your colleague, had invested in your company, or was considering giving you money to deliver some product and you refused to tell me when you think it'll be done, it would be the last time any of the above ever happened. You wouldn't accept that from any service you were attempting to hire, so I don't know why it would be acceptable for software development.
      - wpietri 10mo ago
        I feel like I've already answered the how question elsewhere. But the short version is a product-driven kanban-ish approach with frequent releases, small units of work, and engaged product management focused on actual real-world goals. This approach originated 25 years ago in Kent Beck's "Extreme Programming". Which did start with estimates, but teams doing well at it quickly realized (via said regular reflection) that they could do without it and still deliver well. That some random person on the internet who wouldn't have hired me anyhow will now not hire me is a blow I'll have to learn to live with. But I have literal decades of stakeholders happy working this way. One way that happens is that they pick a date and then we built what fits between now and then. So they get the date, but no promises about what will get delivered. In practice people like this better because beyond a certain very coarse level, estimates are about feelings of engagement and control. What this approach gives them instead is not just feelings, but actual engagement and control. What they get from me is not some unreliable bullshit date, but a commitment to deliver useful things early and often, so that we can together discover something better than their initial visions. And yes, of course I accept this from people who do work for me. My side hustle is starting a pinball museum. When volunteers take on repairing a just-arrived machine, I never ask them for estimates. I ask them to focus on doing it right. They discover problems, figure out how to fix them, and try it out to see if there are more problems. The work takes as long as it takes. Or I hired a friend to design the logo. I never asked for a date. We iterated on it, discovering an number of things along the way, including through user tests. It took a lot longer than I would have guessed, and that's great, because it turned out better than I could have hoped. I understand that this is unfamiliar to people, and apparently it's quite upsetting. But I swear this works. There are more things, Horatio.
- mpyne 10mo ago
  There are agile methods that forgo estimates and deadlines though This is what "agile" is: https://agilemanifesto.org/ https://agilemanifesto.org/ More specific methodologies that say they are agile may use concepts like estimates (story points or time or whatever), but even with Scrum I've never run into a Scrum-imposed "deadline". In Scrum the sprint ends, yes, but sprints often end without hitting all the sprint goals and that, in conjunction with whatever you were able to deliver, just informs your backlog for the next sprint. Real "hard" deadlines are usually imposed by the business stakeholders. But with agile methods the thing they try to do most of all isn't manage deadlines, but maximize pace at which you can understand and solve a relevant business problem. That can often be just as well done by iteratively shipping and adjusting at high velocity, but without a lot of time spent on estimates or calendar management.
  - bpt3 10mo ago
    Yes, people keep linking to the agile manifesto as if it's some sort of amulet protecting software developers from any sort of accountability or responsibility for their work product in a professional setting. It seems like you acknowledge some amount of estimating is needed and I agree that there is an overemphasis on estimation in many places, but I'll ask you the same thing I asked others, which is: How do you do either of the following without spending any time at all on estimates? "Deliver working software frequently, from a couple of weeks to a couple of months, with a preference to the shorter timescale." "At regular intervals, the team reflects on how to become more effective, then tunes and adjusts its behavior accordingly."
    - wpietri 10mo ago
      I addressed the rest elsewhere, but done well a lack of estimates makes people more accountable. If I am shipping something every week (or as is common for my teams, more often), stakeholders can directly evaluate progress. There's no snowing them with paperwork and claims of progress against semi-fictional documents. They see what they see, they try it out, they watch people use it. The reality of use is what we in software are ultimately accountable to, and that's what I am suggesting people optimize for. Closing that feedback loop early and often builds stakeholder trust such that they stop asking for elaborate fantasy plans and estimates.
- wpietri 10mo ago
  I can say with some confidence, having been involved in the movement since before the term "Agile" was coined, that it requires neither. I grant that both of those are common, but that's because the median "Agile" implementation quickly devolved into mini-Waterfall with more hip names.
davidhyde 10mo ago
< “Those often require estimates in much the same way they're required from Star Trek's engineers: so the people with main character syndrome have something to dramatically ignore or override to prove their dominance over the NPCs and material reality.” This is so good.
- wpietri 10mo ago
  Thanks. It was hard won. I spent maybe a decade naively thinking that if we just made software methods that worked in service of stated business goals and values, they'd get adopted and we'd all live happily ever after. It took me a long time to come to grips with the POSIWID [1] version of the purpose of planning and estimates. One of the things that really blew my mind is Mary Poppendieck's story about how they built the Empire State Building on time and under budget even though they didn't have it fully designed when they started. [2] Different, more effective approaches are not only possible, they exist. But they can no longer win out, and I think it's because of the rise of managerialism, the current dominant ideology and culture of big business. [3] [1] https://en.wikipedia.org/wiki/The_purpose_of_a_system_is_what_it_does https://en.wikipedia.org/wiki/The_purpose_of_a_system_is_wha... [2] Talk: https://www.infoq.com/presentations/tyranny-of-plan/ https://www.infoq.com/presentations/tyranny-of-plan/ And transcript: https://web.archive.org/web/20140311004931/https://chrisgagne.com/1255/mary-poppendiecks-the-tyranny-of-the-plan/ https://web.archive.org/web/20140311004931/https://chrisgagn... [3] See, e.g., https://www.amazon.com/Confronting-Managerialism-Business-Economic-Controversies/dp/178032071X https://www.amazon.com/Confronting-Managerialism-Business-Ec...
  - davidhyde 10mo ago
    Thanks for the links. To the limit of my influence I try to protect my team from distractions, be fluid about methodology (constant agile churn can be depressing), limit the toxicity of pull requests, and to spend as much time with them as I can. A happy team is a productive team. Oh and I try not to work with leaders who obsess over Gantt charts. To me estimates are more about trust and respect rather than metrics and velocity. It has to be the right kind of company though.
- 10mo ago
9dev 10mo ago
> As you say, worthwhile software is usually novel. This is an interesting assumption. I’d argue that the overwhelming majority of software is the most boring LoB CRUD apps you can imagine, and not novel at all. Yet, people need to estimate the tasks on these projects as well.
- wpietri 10mo ago
  And starting in the late 1970s, there were tools available to simplify building LoB CRUD apps. [1] That has continued with things like Rails and Salesforce and no-code tooling. If something is truly boring in software, it gets turned into a library or a tool for non-programmers to use. Our value is always driven by the novelty of the need. And no, people don't need to estimate the tasks. My dad did LoB apps in the 1970s to the 1990s. E.g., order entry and shop floor management systems for office furniture factories. His approach was to get something basic working, see how it worked for the users, and then iteratively improve things until they'd created enough business advantage and/or cost savings to move on. Exploratory, iterative work like that can at best be done with broad ballpark estimates. I grant that people want estimates. But that is usually about managerial fear of waste and/or need for control. But I think there are better ways to solve those problems. [1] e.g., https://en.wikipedia.org/wiki/DBase https://en.wikipedia.org/wiki/DBase
  - 9dev 10mo ago
    All of that is besides the point. People need to estimate their tasks if their managers want them to, and no amount of philosophical navel-gazing will change that.
    - xGLaDER 10mo ago
      Because "the manager says so" or because "estimates actually add some value"? I think it's important that our "work culture" allows us to critique why we do certain tasks. When push comes to shove, I guess a manager can say: "Because I say so!", but I also hope those kind of managers are few and far between.
dotancohen 10mo ago
> worthwhile software is usually novel. Another type of worthwhile software is business CRUD. And unfortunately in my experience even for these mundane types of tasks time estimates are typically misjudged - for a multitude of reasons. The typical reason is that developers in large teams often don't know all the places where a field may be used - and their IDE could very well miss some. So automated testing or QA finds an issue, and then the unaccounted-for, time-consuming bugtracking begins. CRUD: Create, Read, Update, Delete. Basically just inputting and displaying data from a database.

by wpietri 10mo ago

bpt3 10mo ago

The solution you described is basically agile, and that definitely includes estimates and deadlines.

Mtinie 10mo ago
It’s Agile philosophically, and how it should be. But that is rarely how it works. In the dozens of different projects across ten or twelve companies I’ve had insight into, “doing Agile” is analogous with “we have a scrum master, hold stand ups, and schedule iterations” while the simple reality is “Agilefall.”
- bpt3 10mo ago
  Agreed, but the parent poster said that estimates shouldn't be done at all, which is not a legitimate argument to make in any scenario.
  - collingreen 10mo ago
    I, and others, don't agree with the blanket statement that "no estimates" is not a legitimate argument in any scenario. Can you expand on why you think there isn't a single case where estimates don't add value? Similarly, is there anything specifically in that post's claims that you think was incorrect, leading to their false conclusion?
    - bpt3 10mo ago
      Okay, a scenario where you're building a hobby project alone and you don't care if or when it gets finished would be one where estimates aren't needed. There is no scenario where it's appropriate or necessary when developing software professionally or even as a side project where others are expecting you to complete work at some point. One of the many misconceptions in the original comment in this thread is that "worthwhile software is usually novel", which is not the case without a very specific and novel definition of worthwhile that I don't believe was intended.
      - kragen 10mo ago
        If software isn't novel, that means some other, existing software does the same thing just as well in the same way on the same platform. So, unless it's a hobby project you're building alone, why don't you just use the existing software? I think that writing software that isn't novel fails to be worthwhile by a perfectly ordinary, mainstream definition of "worthwhile".
        bpt3 10mo ago
        So you would consider a CRUD app with some basic business rules to be novel? Basically meaning that any software that requires any development effort is novel? That's a completely valid definition of worthwhile software, but to claim it's impossible to create an estimate to complete said development is absurd.
        collingreen 10mo ago
wild_egg 10mo ago
I missed that part of the manifesto
- wpietri 10mo ago
  Right? For those who want to check, the four values: https://agilemanifesto.org/ https://agilemanifesto.org/ And the 12 principles: https://agilemanifesto.org/principles.html https://agilemanifesto.org/principles.html But to my dismay, the Agile world quickly got colonized by certification schemes and consultants targeting large companies, so it rapidly turned into something that a lot of the early people were very disappointed with. I wrote about the dynamic some years back: https://williampietri.com/writing/2011/agiles-second-chasm-and-how-we-fell-in/ https://williampietri.com/writing/2011/agiles-second-chasm-a...
  - bpt3 10mo ago
    How do you do either of the following without spending any time at all on estimates? "Deliver working software frequently, from a couple of weeks to a couple of months, with a preference to the shorter timescale." "At regular intervals, the team reflects on how to become more effective, then tunes and adjusts its behavior accordingly." If I was your colleague, had invested in your company, or was considering giving you money to deliver some product and you refused to tell me when you think it'll be done, it would be the last time any of the above ever happened. You wouldn't accept that from any service you were attempting to hire, so I don't know why it would be acceptable for software development.
    - wpietri 10mo ago
      I feel like I've already answered the how question elsewhere. But the short version is a product-driven kanban-ish approach with frequent releases, small units of work, and engaged product management focused on actual real-world goals. This approach originated 25 years ago in Kent Beck's "Extreme Programming". Which did start with estimates, but teams doing well at it quickly realized (via said regular reflection) that they could do without it and still deliver well. That some random person on the internet who wouldn't have hired me anyhow will now not hire me is a blow I'll have to learn to live with. But I have literal decades of stakeholders happy working this way. One way that happens is that they pick a date and then we built what fits between now and then. So they get the date, but no promises about what will get delivered. In practice people like this better because beyond a certain very coarse level, estimates are about feelings of engagement and control. What this approach gives them instead is not just feelings, but actual engagement and control. What they get from me is not some unreliable bullshit date, but a commitment to deliver useful things early and often, so that we can together discover something better than their initial visions. And yes, of course I accept this from people who do work for me. My side hustle is starting a pinball museum. When volunteers take on repairing a just-arrived machine, I never ask them for estimates. I ask them to focus on doing it right. They discover problems, figure out how to fix them, and try it out to see if there are more problems. The work takes as long as it takes. Or I hired a friend to design the logo. I never asked for a date. We iterated on it, discovering an number of things along the way, including through user tests. It took a lot longer than I would have guessed, and that's great, because it turned out better than I could have hoped. I understand that this is unfamiliar to people, and apparently it's quite upsetting. But I swear this works. There are more things, Horatio.
mpyne 10mo ago
There are agile methods that forgo estimates and deadlines though This is what "agile" is: https://agilemanifesto.org/ https://agilemanifesto.org/ More specific methodologies that say they are agile may use concepts like estimates (story points or time or whatever), but even with Scrum I've never run into a Scrum-imposed "deadline". In Scrum the sprint ends, yes, but sprints often end without hitting all the sprint goals and that, in conjunction with whatever you were able to deliver, just informs your backlog for the next sprint. Real "hard" deadlines are usually imposed by the business stakeholders. But with agile methods the thing they try to do most of all isn't manage deadlines, but maximize pace at which you can understand and solve a relevant business problem. That can often be just as well done by iteratively shipping and adjusting at high velocity, but without a lot of time spent on estimates or calendar management.
- bpt3 10mo ago
  Yes, people keep linking to the agile manifesto as if it's some sort of amulet protecting software developers from any sort of accountability or responsibility for their work product in a professional setting. It seems like you acknowledge some amount of estimating is needed and I agree that there is an overemphasis on estimation in many places, but I'll ask you the same thing I asked others, which is: How do you do either of the following without spending any time at all on estimates? "Deliver working software frequently, from a couple of weeks to a couple of months, with a preference to the shorter timescale." "At regular intervals, the team reflects on how to become more effective, then tunes and adjusts its behavior accordingly."
  - wpietri 10mo ago
    I addressed the rest elsewhere, but done well a lack of estimates makes people more accountable. If I am shipping something every week (or as is common for my teams, more often), stakeholders can directly evaluate progress. There's no snowing them with paperwork and claims of progress against semi-fictional documents. They see what they see, they try it out, they watch people use it. The reality of use is what we in software are ultimately accountable to, and that's what I am suggesting people optimize for. Closing that feedback loop early and often builds stakeholder trust such that they stop asking for elaborate fantasy plans and estimates.
wpietri 10mo ago
I can say with some confidence, having been involved in the movement since before the term "Agile" was coined, that it requires neither. I grant that both of those are common, but that's because the median "Agile" implementation quickly devolved into mini-Waterfall with more hip names.

davidhyde 10mo ago

< “Those often require estimates in much the same way they're required from Star Trek's engineers: so the people with main character syndrome have something to dramatically ignore or override to prove their dominance over the NPCs and material reality.” This is so good.

wpietri 10mo ago
Thanks. It was hard won. I spent maybe a decade naively thinking that if we just made software methods that worked in service of stated business goals and values, they'd get adopted and we'd all live happily ever after. It took me a long time to come to grips with the POSIWID [1] version of the purpose of planning and estimates. One of the things that really blew my mind is Mary Poppendieck's story about how they built the Empire State Building on time and under budget even though they didn't have it fully designed when they started. [2] Different, more effective approaches are not only possible, they exist. But they can no longer win out, and I think it's because of the rise of managerialism, the current dominant ideology and culture of big business. [3] [1] https://en.wikipedia.org/wiki/The_purpose_of_a_system_is_what_it_does https://en.wikipedia.org/wiki/The_purpose_of_a_system_is_wha... [2] Talk: https://www.infoq.com/presentations/tyranny-of-plan/ https://www.infoq.com/presentations/tyranny-of-plan/ And transcript: https://web.archive.org/web/20140311004931/https://chrisgagne.com/1255/mary-poppendiecks-the-tyranny-of-the-plan/ https://web.archive.org/web/20140311004931/https://chrisgagn... [3] See, e.g., https://www.amazon.com/Confronting-Managerialism-Business-Economic-Controversies/dp/178032071X https://www.amazon.com/Confronting-Managerialism-Business-Ec...
- davidhyde 10mo ago
  Thanks for the links. To the limit of my influence I try to protect my team from distractions, be fluid about methodology (constant agile churn can be depressing), limit the toxicity of pull requests, and to spend as much time with them as I can. A happy team is a productive team. Oh and I try not to work with leaders who obsess over Gantt charts. To me estimates are more about trust and respect rather than metrics and velocity. It has to be the right kind of company though.
10mo ago

9dev 10mo ago

> As you say, worthwhile software is usually novel. This is an interesting assumption. I’d argue that the overwhelming majority of software is the most boring LoB CRUD apps you can imagine, and not novel at all. Yet, people need to estimate the tasks on these projects as well.

wpietri 10mo ago
And starting in the late 1970s, there were tools available to simplify building LoB CRUD apps. [1] That has continued with things like Rails and Salesforce and no-code tooling. If something is truly boring in software, it gets turned into a library or a tool for non-programmers to use. Our value is always driven by the novelty of the need. And no, people don't need to estimate the tasks. My dad did LoB apps in the 1970s to the 1990s. E.g., order entry and shop floor management systems for office furniture factories. His approach was to get something basic working, see how it worked for the users, and then iteratively improve things until they'd created enough business advantage and/or cost savings to move on. Exploratory, iterative work like that can at best be done with broad ballpark estimates. I grant that people want estimates. But that is usually about managerial fear of waste and/or need for control. But I think there are better ways to solve those problems. [1] e.g., https://en.wikipedia.org/wiki/DBase https://en.wikipedia.org/wiki/DBase
- 9dev 10mo ago
  All of that is besides the point. People need to estimate their tasks if their managers want them to, and no amount of philosophical navel-gazing will change that.
  - xGLaDER 10mo ago
    Because "the manager says so" or because "estimates actually add some value"? I think it's important that our "work culture" allows us to critique why we do certain tasks. When push comes to shove, I guess a manager can say: "Because I say so!", but I also hope those kind of managers are few and far between.

dotancohen 10mo ago

> worthwhile software is usually novel. Another type of worthwhile software is business CRUD. And unfortunately in my experience even for these mundane types of tasks time estimates are typically misjudged - for a multitude of reasons. The typical reason is that developers in large teams often don't know all the places where a field may be used - and their IDE could very well miss some. So automated testing or QA finds an issue, and then the unaccounted-for, time-consuming bugtracking begins. CRUD: Create, Read, Update, Delete. Basically just inputting and displaying data from a database.