3 ms·

> I'm confused that they can put a time frame on a problem they have no idea how to solve yet. You are writing on a developer forum, they work in Agile and ruo

> I'm confused that they can put a time frame on a problem they have no idea how to solve yet. You are writing on a developer forum, they work in Agile and ruotinely provide estimates or work to deadlines when business does not even know the requirements of their system, let alone how to build most of it.

lazide 4y ago
If a developer tells you they can deliver by x, and they also don't know how to do it, what is the level of confidence you have that will occur?
- epistasis 4y ago
  This paper is saying they can deliver by x, if y is figured out. It's a perfectly cromulent way to make a projection.
  - lazide 4y ago
    Where we have no idea of how expensive or not y will be, or how long it will take to do it. Like saying ‘The UI will be ready in 6 months if the backend is figured out’. Also not a realistic projection. Don’t get me wrong, it’s something. But the error bars are larger than the graph.
    - epistasis 4y ago
      I'm sorry, but that characterization of 90% versus 100% is not remotely fair. "Only 90% unless people let us buy enough land" is a far cry from not having any clue at all.
      - lazide 4y ago
        It isn’t just land though, it’s also storage and other tech. Aka ‘the backend’. Or ‘the other 90%’
- wankle 4y ago
  As a developer, the ugly truth about Agile is that something (TM) is delivered and fallout is labeled Technical Debt.
  - lazide 4y ago
    Been there, done that, literally got all the t-shirts. One challenge I’ve seen though, in the situations where that’s what happened, is that I didn’t see at the time (and still, looking back, don’t see) any alternative that was likely to work either. But no one likes that answer, especially not the folks paying for it. Most of the difficulty was just figuring out what needed to be done, not sitting down and actually doing it. And software is so incredibly picky, it was always in doubt for many projects if it was actually going to work well enough until the hard parts were all almost done anyway. CRUD apps? Sure, not as hard - but even there it’s common to run across issues like ‘that doesn’t actually make sense to do’ once you go to actually do it. The new checkbox makes everything really confusing, or it tips the whole CRUd page into ‘too many things’ without a rethink, or if the bit of data that logically is associated with everything else is actually stored in a different backend, and the semantics of clicking ‘Save’ get too scary if you combine them all. Waterfall, while pushing forward some of the planning, can help compared to what Agile has devolved to sometimes - like people literally not trying to figure out what they even want to do this week. Waterfall was always an issue because the plans just get more unrealistic because the time to discovery of issues gets bigger, and everyone spends tons of time churning in their GANTT charts instead of just trying it, or realizing you can’t plan something accurately if you don’t know if it will work and being honest about it. And then tighten the screws when the people doing the work are late. It’s a story about overwhelm, in my experience. Most business problems are always in need of more decision making ability, and process tends to be used as a crutch instead of solving that problem.
- Dylan16807 4y ago
  I'm not much less confident than if they do know how to do it.

lazide 4y ago

If a developer tells you they can deliver by x, and they also don't know how to do it, what is the level of confidence you have that will occur?

epistasis 4y ago
This paper is saying they can deliver by x, if y is figured out. It's a perfectly cromulent way to make a projection.
- lazide 4y ago
  Where we have no idea of how expensive or not y will be, or how long it will take to do it. Like saying ‘The UI will be ready in 6 months if the backend is figured out’. Also not a realistic projection. Don’t get me wrong, it’s something. But the error bars are larger than the graph.
  - epistasis 4y ago
    I'm sorry, but that characterization of 90% versus 100% is not remotely fair. "Only 90% unless people let us buy enough land" is a far cry from not having any clue at all.
    - lazide 4y ago
      It isn’t just land though, it’s also storage and other tech. Aka ‘the backend’. Or ‘the other 90%’
wankle 4y ago
As a developer, the ugly truth about Agile is that something (TM) is delivered and fallout is labeled Technical Debt.
- lazide 4y ago
  Been there, done that, literally got all the t-shirts. One challenge I’ve seen though, in the situations where that’s what happened, is that I didn’t see at the time (and still, looking back, don’t see) any alternative that was likely to work either. But no one likes that answer, especially not the folks paying for it. Most of the difficulty was just figuring out what needed to be done, not sitting down and actually doing it. And software is so incredibly picky, it was always in doubt for many projects if it was actually going to work well enough until the hard parts were all almost done anyway. CRUD apps? Sure, not as hard - but even there it’s common to run across issues like ‘that doesn’t actually make sense to do’ once you go to actually do it. The new checkbox makes everything really confusing, or it tips the whole CRUd page into ‘too many things’ without a rethink, or if the bit of data that logically is associated with everything else is actually stored in a different backend, and the semantics of clicking ‘Save’ get too scary if you combine them all. Waterfall, while pushing forward some of the planning, can help compared to what Agile has devolved to sometimes - like people literally not trying to figure out what they even want to do this week. Waterfall was always an issue because the plans just get more unrealistic because the time to discovery of issues gets bigger, and everyone spends tons of time churning in their GANTT charts instead of just trying it, or realizing you can’t plan something accurately if you don’t know if it will work and being honest about it. And then tighten the screws when the people doing the work are late. It’s a story about overwhelm, in my experience. Most business problems are always in need of more decision making ability, and process tends to be used as a crutch instead of solving that problem.
Dylan16807 4y ago
I'm not much less confident than if they do know how to do it.