4 ms·

What happens to project planning when tasks and dependents form cycles? Doesn't that happen pretty often?

Jtsummers 6y ago
If you have a cyclic dependency in your project then you more likely have a DAG that’s not sufficiently broken down. That is if A and B seem to depend on each other you have some sub tasks in each that need to be pulled out. If this still fails to break the apparent cycle, you’ve got a problem. Another thing to keep in mind is that there's a distinction between a system having cyclic dependencies (I need A & B working because they communicate with each other), and the task ordering. During development you can end up with a partially correct system. If A sends to B, and B sends to A but I only have one person working on both parts, then it's possible I'll end up in a state where A sends to B but not the reverse. That's fine during development. Yes, the system is "wrong" per the design or spec. But it's a partial system (like a half-built bridge). Your tasks will appear to have a cycle, but in reality you will break it by selecting one portion to complete first so in the end it remains (based on the chosen path) a DAG.
- jlokier 6y ago
  > That is if A and B seem to depend on each other you have some sub tasks in each that need to be pulled out. That produces subtasks without cycles, giving you a way forward. Assuming you still want to maintain shared information about the tasks which contain subtasks, those tasks still have a dependency cycle between them though, which is correct because tasks are often like that - they need to move forward together.
- projektfu 6y ago
  I assume a decent plan willbe hard to make without understanding that a sizeable portion will have to be reworked. (In software at least). For example, the Boehm model. How do you make a Gantt chart without abstracting away the whole project?
TeMPOraL 6y ago
There shouldn't be any cycles in properly broken out plan, because the flow of time creates a causal directness; a true cycle would prevent any of the tasks involved from starting, which obviously doesn't happen in real life. Sometimes you may need to break things down a bit more. And that's why I'm asking for a tool that lets me model projects as Directed Acyclic Graphs of tasks. Because all I seem to be getting in popular tools is a flat list with some categorizing, or a single level of subtasks at best. I want to be able to express directly that this subtask has sub-subtasks, and that this sub-subtask depends on completion of a subtask from some other task (without making it a dependency between root tasks).
- dragonwriter 6y ago
  > There shouldn't be any cycles in properly broken out plan, because the flow of time creates a causal directness Real dependencies can be not-before rather than strictly-after, which admits cycles without any problems with the flow of time.
  - TeMPOraL 6y ago
    Then I'm fine with a cyclic graph.
    - projektfu 6y ago
      Cool discussion. Thanks all.
- spirobel 6y ago
  maybe you can split the task into its subtasks and forget about the task itself. Then you forget about the concept of subtasks and you are left with a bunch of tasks. now you can define dependencies between these tasks like you would normaly do.

If you have a cyclic dependency in your project then you more likely have a DAG that’s not sufficiently broken down. That is if A and B seem to depend on each other you have some sub tasks in each that need to be pulled out. If this still fails to break the apparent cycle, you’ve got a problem. Another thing to keep in mind is that there's a distinction between a system having cyclic dependencies (I need A & B working because they communicate with each other), and the task ordering. During development you can end up with a partially correct system. If A sends to B, and B sends to A but I only have one person working on both parts, then it's possible I'll end up in a state where A sends to B but not the reverse. That's fine during development. Yes, the system is "wrong" per the design or spec. But it's a partial system (like a half-built bridge). Your tasks will appear to have a cycle, but in reality you will break it by selecting one portion to complete first so in the end it remains (based on the chosen path) a DAG.

jlokier 6y ago
> That is if A and B seem to depend on each other you have some sub tasks in each that need to be pulled out. That produces subtasks without cycles, giving you a way forward. Assuming you still want to maintain shared information about the tasks which contain subtasks, those tasks still have a dependency cycle between them though, which is correct because tasks are often like that - they need to move forward together.
projektfu 6y ago
I assume a decent plan willbe hard to make without understanding that a sizeable portion will have to be reworked. (In software at least). For example, the Boehm model. How do you make a Gantt chart without abstracting away the whole project?

TeMPOraL 6y ago

There shouldn't be any cycles in properly broken out plan, because the flow of time creates a causal directness; a true cycle would prevent any of the tasks involved from starting, which obviously doesn't happen in real life. Sometimes you may need to break things down a bit more. And that's why I'm asking for a tool that lets me model projects as Directed Acyclic Graphs of tasks. Because all I seem to be getting in popular tools is a flat list with some categorizing, or a single level of subtasks at best. I want to be able to express directly that this subtask has sub-subtasks, and that this sub-subtask depends on completion of a subtask from some other task (without making it a dependency between root tasks).

dragonwriter 6y ago
> There shouldn't be any cycles in properly broken out plan, because the flow of time creates a causal directness Real dependencies can be not-before rather than strictly-after, which admits cycles without any problems with the flow of time.
- TeMPOraL 6y ago
  Then I'm fine with a cyclic graph.
  - projektfu 6y ago
    Cool discussion. Thanks all.
spirobel 6y ago
maybe you can split the task into its subtasks and forget about the task itself. Then you forget about the concept of subtasks and you are left with a bunch of tasks. now you can define dependencies between these tasks like you would normaly do.