5 ms·

> Have you noticed how Apple ships most of their big bang projects at WWDC, a date they commit to far ahead? Is this why so many Apple products have been incre

> Have you noticed how Apple ships most of their big bang projects at WWDC, a date they commit to far ahead? Is this why so many Apple products have been increasingly low-quality? Instead of committing to quality, they commit to arbitrary dates because some bean counter decides quarterly profits needed to be higher. I don’t disagree that we should estimate, but I think we should be realistic about just how difficult estimating software projects is, especially now that we’re “agile”, which really means “there aren’t any explicit requirements but there are requirements, we just don’t know what they are and also they change every sprint so good luck”. If we want to estimate software, we need to have more predictability. I can estimate that it takes three days to fix a bug, but what happens when I pull those covers back and see an unholy Eldritch abomination? I could redo my estimate, but what if I run into an arbitrary quarterly profit-driven date? “Well, just get it done.” Then we nail some more legs to the dog and the cycle continues.

delusional 7y ago
> there aren’t any explicit requirements but there are requirements, we just don’t know what they are and also they change every sprint so good luck What a sad way to view your profession. The requirements aren't hidden from you, and they don't just randomly change. You can't get them up front because no one has any idea what we are looking for. Solving a small problem usually reveals more of the problem. I don't think you believe in long requirement documents either, but I sometimes hear arguments very similar to yours.
- ThalesX 7y ago
  What a sad way to hammer someone’s view of his profession based on a comment. > You can’t get them up front because no one has any idea what we are looking for. Is this requirement implementation or R&D? While it’s understandable for R&D to be exist within the ‘no one has any idea what we are looking for’, to fit all software development into this paradigm is to have a pretty lax understanding of how most software operates... > Solving a small problem usually reveals more of the problem This is exactly what I think the parent post was arguing when shying away from estimates.
- lifeisstillgood 7y ago
  Our understanding of the problem evolves alongside the solutions - and when we look back we tends to say "how could we have been so dumb when we planned this" But we literally did not know
- jayd16 7y ago
  New information is constantly becoming available, therefore more requirements are revealed. That's exactly the same as saying the set of requirements constantly changes.
- journalctl 7y ago
  It is sad, isn’t it? I wish it didn’t happen so frequently, and I wish my concerns weren’t dismissed so flippantly. How fortunate I am to have met someone who knows more about my situation than I do.
davidjnelson 7y ago
> there aren’t any explicit requirements but there are requirements, we just don’t know what they are and also they change every sprint so good luck Yikes, too true! What about confidence intervals? I’ve found that’s a solution that makes the most people the least unhappy.
abhorrence 7y ago
> Is this why so many Apple products have been increasingly low-quality? Potentially, however the author makes another mistake: assuming that Apple, Google or Facebook actually know what they're launching at the time they set the date. I've heard many stories of "big bang projects" being pulled at the last minute.
- delusional 7y ago
  I would actually believe it to be the opposite. If you know you will be attending a big event, and you have a project that seems feature complete. It might make sense to hold out releasing it for a couple of months until the conference. If you're a big enough enterprise it seems likely you will always have something finishing up.
- ghaff 7y ago
  Pretty much every big company has big conferences that they "need" to announce appropriate stuff at. In my experience, you end up with a combination of changing what you announce, announcing what you planned but without immediate availability (especially if it doesn't obsolete a current product), dropping features, and prioritizing work on what you really want/need to announce. Historically, the software industry has been more fluid with its announcement cadence that, say, the auto industry. But companies still have big events at which they really want to make high visibility announcements.
pas 7y ago
No estimation without experience. This works. New team? Needs time to get average velocity (burn down rate), about a month. Greenfield project? Need time to figure out how complex the domain is, again at least month, maybe two. Sure, you can still have deadlines, but keeping them without real data to base estimates on will require feature cuts (or more resources, but by the time it becomes clear it's too late).
Haga 7y ago
Agile is just the Ikea effect in action. Nobody blamed the chair- if he made it himself.

delusional 7y ago

> there aren’t any explicit requirements but there are requirements, we just don’t know what they are and also they change every sprint so good luck What a sad way to view your profession. The requirements aren't hidden from you, and they don't just randomly change. You can't get them up front because no one has any idea what we are looking for. Solving a small problem usually reveals more of the problem. I don't think you believe in long requirement documents either, but I sometimes hear arguments very similar to yours.

ThalesX 7y ago
What a sad way to hammer someone’s view of his profession based on a comment. > You can’t get them up front because no one has any idea what we are looking for. Is this requirement implementation or R&D? While it’s understandable for R&D to be exist within the ‘no one has any idea what we are looking for’, to fit all software development into this paradigm is to have a pretty lax understanding of how most software operates... > Solving a small problem usually reveals more of the problem This is exactly what I think the parent post was arguing when shying away from estimates.
lifeisstillgood 7y ago
Our understanding of the problem evolves alongside the solutions - and when we look back we tends to say "how could we have been so dumb when we planned this" But we literally did not know
jayd16 7y ago
New information is constantly becoming available, therefore more requirements are revealed. That's exactly the same as saying the set of requirements constantly changes.
journalctl 7y ago
It is sad, isn’t it? I wish it didn’t happen so frequently, and I wish my concerns weren’t dismissed so flippantly. How fortunate I am to have met someone who knows more about my situation than I do.

davidjnelson 7y ago

> there aren’t any explicit requirements but there are requirements, we just don’t know what they are and also they change every sprint so good luck Yikes, too true! What about confidence intervals? I’ve found that’s a solution that makes the most people the least unhappy.

abhorrence 7y ago

> Is this why so many Apple products have been increasingly low-quality? Potentially, however the author makes another mistake: assuming that Apple, Google or Facebook actually know what they're launching at the time they set the date. I've heard many stories of "big bang projects" being pulled at the last minute.

delusional 7y ago
I would actually believe it to be the opposite. If you know you will be attending a big event, and you have a project that seems feature complete. It might make sense to hold out releasing it for a couple of months until the conference. If you're a big enough enterprise it seems likely you will always have something finishing up.
ghaff 7y ago
Pretty much every big company has big conferences that they "need" to announce appropriate stuff at. In my experience, you end up with a combination of changing what you announce, announcing what you planned but without immediate availability (especially if it doesn't obsolete a current product), dropping features, and prioritizing work on what you really want/need to announce. Historically, the software industry has been more fluid with its announcement cadence that, say, the auto industry. But companies still have big events at which they really want to make high visibility announcements.

pas 7y ago

No estimation without experience. This works. New team? Needs time to get average velocity (burn down rate), about a month. Greenfield project? Need time to figure out how complex the domain is, again at least month, maybe two. Sure, you can still have deadlines, but keeping them without real data to base estimates on will require feature cuts (or more resources, but by the time it becomes clear it's too late).

Haga 7y ago

Agile is just the Ikea effect in action. Nobody blamed the chair- if he made it himself.