|
> 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. |