[progval]

> Couldn't you have one main task which describes the overall task and then it has a list with checkboxes that has links to the other tasks it depends on?

That only works for trees of tasks, ie. when a task is a dependency of at most one other task.

Imagine you have two high-level tasks: "repair the chair" and "repair the computer", which both depends on the task "buy a screwdriver". Without support for DAGs of tasks, you would need a "buy a screwdriver" bullet point in both tasks, and remember to check both after you buy it.

[flakeoil]

I get your point.

In that case I would have created a task "buy a screwdriver" with a relatively high priority or scheduled before the other tasks and maybe link to or comment about the other tasks as motivation to why the screwdriver is needed.

In practice, when using basic to-do apps like the one mentioned here for simpler projects such as re-build the living room or a one-man software project or just some around-the-house projects then I think a DAG is a bit overkill and complicated. You would also need to remember to connect the screwdriver dependency to any new task that depends on it and also avoid creating a new duplicate "buy screwdriver" task as you did not know/find the already existing one.

For projects such as "build the next generation 747", for sure something DAG like is needed.

[TeMPOraL]

> In practice, when using basic to-do apps like the one mentioned here for simpler projects

The problem is, a big chunk of the software industry seems to be managed by basic to-do apps like Trello (or worse, Github/Gitlab issues).

> such as re-build the living room or a one-man software project or just some around-the-house projects then I think a DAG is a bit overkill and complicated

It depends on a project. In my experience, "overkill" manifests primarily as you spending too much time constantly tweaking the task graph. There's a point past which it's better to stick to a tree, or even a flat list, and use your own memory and common sense to manage dependencies. This is, however, affected by UX to a large degree - the easier and faster it is to "sculpt" the DAG, the smaller are the minimal projects for which this is better than a list + some extra cognitive effort.

With personal/single-person projects, I found that DAGs become more and more useful the more different aspects of it you have to track, and the greater the length of the project is. For adding a simple feature to a codebase DAGs are definitely an overkill. But for remodeling an apartment, or even "re-building the living room", it's a different story: this is the kind of project that has lots of independent concerns, requires ahead-of-time planning and thinking of contingencies, and will take months of you being involved an hour or three a day on average. You're not going to be "in the flow" in such project - you'll be re-entering it every day. DAGs help you understand the current state quickly, and prevent getting overwhelmed by the sheer size of it.

Though the most important thing I've learned so far is: don't overdo it. You probably don't need a 100+ nodes large DAG for remodeling a living room. Not because it's wrong, but because any new information, situation or realization will force you to remodel a part of the DAG, and you'll end up spending more time keeping the plan up to date than on the actual project itself.