3 ms·

I hate that Rich Hickey quote. Sprints are just the classic computer science "divide and conquer" strategy applied to development.

GuiA 7y ago
That’s quite the leaky metaphor. If you split a list in half to sort it, the computer doesn’t inherit the backlog of punted features/bugs/stress/frustration/etc from the previous half.
deleted 7y ago
[deleted]
ken 7y ago
The why not use a word that doesn’t imply “go at an unsustainable pace”? There are plenty of good ones to choose from.
AgloeDreams 7y ago
The problem with divide and conquer is that the finished product has to be back in one piece that makes sense. Often times the act of `divide` also reduces context for what conquer actually is. Plus `divide and conquer` is used like a task you need to do with the goal of finishing, but Sprints never quite get to the end of the conquer phase, generally it's divide, and conquer...some tasks, and then divide in some more... and more... and more. You end up losing all sight of what you are actually trying to do or make. The only way to fix sprints in a small to medium size company that exists and is shipping products is to realize that they should be tied to a set series of tasks and that every now and then you really need a stop point where you can take a week or two, define what your goals, needs, and issues are for the next 6 weeks or so, and then start anew with a clean backlog and roadmap with full buy in from the developers of what they are making. Otherwise you just turn developers into ticket pushers for tickets that they themselves do not understand, or have any context to understand why they are doing them. It's depressing and causes burnout and bad products. It's a symptom of the hustle culture bleeding into development and a lack of understanding that having long term end goals and sustainable pace is healthy to good products rather than `move fast and break things`.
coldtea 7y ago
>Sprints are just the classic computer science "divide and conquer" strategy applied to development. The classic computer science "divide and conquer" (quicksort being a canonical example) has no state to carry over from one divided part to the next. Divided parts should also be interchangeable -- whereas in sprints they aren't -- they're different stages of a release/feature, with different stuff to be done in each. Finally, sprint is a total misnomer for "divide and conquer" -- as its very definition is about giving it all for a short time from start to end (a small race). It's not about dividing parts of a larger race.

GuiA 7y ago

That’s quite the leaky metaphor. If you split a list in half to sort it, the computer doesn’t inherit the backlog of punted features/bugs/stress/frustration/etc from the previous half.

deleted 7y ago

[deleted]

ken 7y ago

The why not use a word that doesn’t imply “go at an unsustainable pace”? There are plenty of good ones to choose from.

AgloeDreams 7y ago

The problem with divide and conquer is that the finished product has to be back in one piece that makes sense. Often times the act of `divide` also reduces context for what conquer actually is. Plus `divide and conquer` is used like a task you need to do with the goal of finishing, but Sprints never quite get to the end of the conquer phase, generally it's divide, and conquer...some tasks, and then divide in some more... and more... and more. You end up losing all sight of what you are actually trying to do or make. The only way to fix sprints in a small to medium size company that exists and is shipping products is to realize that they should be tied to a set series of tasks and that every now and then you really need a stop point where you can take a week or two, define what your goals, needs, and issues are for the next 6 weeks or so, and then start anew with a clean backlog and roadmap with full buy in from the developers of what they are making. Otherwise you just turn developers into ticket pushers for tickets that they themselves do not understand, or have any context to understand why they are doing them. It's depressing and causes burnout and bad products. It's a symptom of the hustle culture bleeding into development and a lack of understanding that having long term end goals and sustainable pace is healthy to good products rather than `move fast and break things`.

coldtea 7y ago

>Sprints are just the classic computer science "divide and conquer" strategy applied to development. The classic computer science "divide and conquer" (quicksort being a canonical example) has no state to carry over from one divided part to the next. Divided parts should also be interchangeable -- whereas in sprints they aren't -- they're different stages of a release/feature, with different stuff to be done in each. Finally, sprint is a total misnomer for "divide and conquer" -- as its very definition is about giving it all for a short time from start to end (a small race). It's not about dividing parts of a larger race.