4 ms·

And when he delivers the API in 2 months, it's not what the customer wants and has a bunch of problems that are difficult to fix because he delivered it all at

And when he delivers the API in 2 months, it's not what the customer wants and has a bunch of problems that are difficult to fix because he delivered it all at once instead of incrementally.

choeger 6y ago
"incremental API", exactly. Did you ever do that in practice or are you just repeating some scrum talking points?
- fvdessen 6y ago
  If the hypothetical API is taking 2 months to implement best case scenario I assume it's doing multiple things and each of those things can be done and tested piecewise.
  - Traster 6y ago
    I really think you're missing the forest for the trees. His point was simply a big task can be broken down into smaller tasks that don't necessarily magically fit into 2 week chunks, and if you pick tasks that you know you can do within 2 weeks, often you're picking between 1-2weeks worth of work, and then the work stretches to fill the time. It's not about how many actual endpoints there are or how you actually choose to split the tasks.
  - choeger 6y ago
    Or maybe, the model is actually just rather complex and a good API cannot be just a bunch of random methods on some losely related entities. Or maybe the non-functional aspects of the implementation need to be carefully considered before releasing an API that makes safety, correctness, security, or performance impossible. Or maybe the developers have an inconsistent specification and delivering piece A now makes it logically impossible to ever deliver piece B, which is arguably more important, but got lower priority because noone took the time to understand the whole thing.
taneq 6y ago
Not all (or even most) software developed is developed in a vacuum for a customer who has no idea what they want. Much software is developed as part of a larger system where functionality is relatively well known in advance and where rapidly iterating on potential UIs and APIs is neither needed nor useful. There's definitely a time and a place for Agile-derived methodologies but not every project is a nail for this particular hammer.
- jrochkind1 6y ago
  > Much software is developed as part of a larger system where functionality is relatively well known in advance Also, however, most software, especially 'enterprise', doesn't actually do what it's users need, and is a nightmare for it's users. That the functionality it would deliver and how it would do so was decided by managers in advance doesn't mean it actually works for those using it.
  - taneq 6y ago
    This is true, much 'enterprise' software is awful. And the key to it is that (as you accurately say) the functionality is decided by managers, rather than being determined by business analysts and UI/UX designers based on the actual users' workflows and feedback. No software development methodology is going to fix that.
    - jrochkind1 6y ago
      Agreed 100%. But once you have people with the responsibility and authority and skill at determining based on actual users' workflows and feedback... in my opinion and experience, iterative design works -- even "rapidly iterating" ideally -- a lot lot better than assuming "functionality is relatively well known in advance", as the GP taneq suggested. Even experts at UX need iterative feedback to get it right, in fact an expert at UX is likely to know and tell you this, that's what their expertise tells them. (And note even OP concludes by saying he does like "agile", just not "scrum" -- so taneq in arguing for avoiding rapid iteration for "functionality relatively well known in advance" is not necessarily making the same evaluation as OP either). Part of what always happens in these discussions is we all come from our experience. I've seen it work, in such a way that convinces me it was because of it's iterative nature that it worked. taneq above, I would guess, has not. As a field, we still haven't done great at working out a methodology to extract/abstract from these differing experiences to general consensus principles, when it comes to "how we write software". So we're all just arguing from our experiences, and such arguments show that experiences really differ. Not sure what to do with that. The arguments just go round and round. I don't think attempts to make this "empirical" and "data-driven" have proven satisfactory, they often seem to suffer from artificiality/lack of validity to me too. (And as far as personal experience -- I think most of us who have been around 10+ years find that our opinions about 'the right way to do it' change over time, as our experiences show us different things; but that doesn't necessarily mean those who have been around longer are more likely to be right and should be defered to; clearly that defering to experience rarely happens anyway).
dogman144 6y ago
Yup, a failure to define an MVP. Not trusting the managers, not trusting the customer, designing a over-time, over-featured API.

And when he delivers the API in 2 months, it's not what the customer wants and has a bunch of problems that are difficult to fix because he delivered it all at once instead of incrementally.

choeger 6y ago

"incremental API", exactly. Did you ever do that in practice or are you just repeating some scrum talking points?

fvdessen 6y ago
If the hypothetical API is taking 2 months to implement best case scenario I assume it's doing multiple things and each of those things can be done and tested piecewise.
- Traster 6y ago
  I really think you're missing the forest for the trees. His point was simply a big task can be broken down into smaller tasks that don't necessarily magically fit into 2 week chunks, and if you pick tasks that you know you can do within 2 weeks, often you're picking between 1-2weeks worth of work, and then the work stretches to fill the time. It's not about how many actual endpoints there are or how you actually choose to split the tasks.
- choeger 6y ago
  Or maybe, the model is actually just rather complex and a good API cannot be just a bunch of random methods on some losely related entities. Or maybe the non-functional aspects of the implementation need to be carefully considered before releasing an API that makes safety, correctness, security, or performance impossible. Or maybe the developers have an inconsistent specification and delivering piece A now makes it logically impossible to ever deliver piece B, which is arguably more important, but got lower priority because noone took the time to understand the whole thing.

taneq 6y ago

Not all (or even most) software developed is developed in a vacuum for a customer who has no idea what they want. Much software is developed as part of a larger system where functionality is relatively well known in advance and where rapidly iterating on potential UIs and APIs is neither needed nor useful. There's definitely a time and a place for Agile-derived methodologies but not every project is a nail for this particular hammer.

jrochkind1 6y ago
> Much software is developed as part of a larger system where functionality is relatively well known in advance Also, however, most software, especially 'enterprise', doesn't actually do what it's users need, and is a nightmare for it's users. That the functionality it would deliver and how it would do so was decided by managers in advance doesn't mean it actually works for those using it.
- taneq 6y ago
  This is true, much 'enterprise' software is awful. And the key to it is that (as you accurately say) the functionality is decided by managers, rather than being determined by business analysts and UI/UX designers based on the actual users' workflows and feedback. No software development methodology is going to fix that.
  - jrochkind1 6y ago
    Agreed 100%. But once you have people with the responsibility and authority and skill at determining based on actual users' workflows and feedback... in my opinion and experience, iterative design works -- even "rapidly iterating" ideally -- a lot lot better than assuming "functionality is relatively well known in advance", as the GP taneq suggested. Even experts at UX need iterative feedback to get it right, in fact an expert at UX is likely to know and tell you this, that's what their expertise tells them. (And note even OP concludes by saying he does like "agile", just not "scrum" -- so taneq in arguing for avoiding rapid iteration for "functionality relatively well known in advance" is not necessarily making the same evaluation as OP either). Part of what always happens in these discussions is we all come from our experience. I've seen it work, in such a way that convinces me it was because of it's iterative nature that it worked. taneq above, I would guess, has not. As a field, we still haven't done great at working out a methodology to extract/abstract from these differing experiences to general consensus principles, when it comes to "how we write software". So we're all just arguing from our experiences, and such arguments show that experiences really differ. Not sure what to do with that. The arguments just go round and round. I don't think attempts to make this "empirical" and "data-driven" have proven satisfactory, they often seem to suffer from artificiality/lack of validity to me too. (And as far as personal experience -- I think most of us who have been around 10+ years find that our opinions about 'the right way to do it' change over time, as our experiences show us different things; but that doesn't necessarily mean those who have been around longer are more likely to be right and should be defered to; clearly that defering to experience rarely happens anyway).

dogman144 6y ago

Yup, a failure to define an MVP. Not trusting the managers, not trusting the customer, designing a over-time, over-featured API.