Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

Breaking down tasks

jacobian.org

Post reply on HN
Print view View original

61–70 of 118 posts

Re: Breaking down tasks

#61

Post by fmbb »

arnorhs wrote: post #60
Scarblac wrote: post #43

I've also done this a lot, as has everybody. My experience is that there are two problems. One, it turns out I never ever end up doing the actual steps as I planned to. After a few I have new insights, realize I forgot something, see an easier way, I don't know -- the plan is never followed. The other is that I really hate working like this because it seems all the creative effort of thinking about how to make someth…

Whenever you talk about breaking down tasks, estimations etc, those usually are for multi-person teams, and/or projects that have some specific budget or something. Of course if you are exploring or building your own projects and/or don't have any other accountability, you wouldn't start planning that.. unless you are really into planning in and of itself. But as soon as you have a boss and the boss asks "how long? w…

> But as soon as you have a boss and the boss asks "how long? who does what? where do we start?" - you have to have some framework.

Why?

Does it work? Is it productive? Is it better than not doing that?

Re: Breaking down tasks

#62

Post by firewolf34 »

globular-toast wrote: post #56

What's missing here is who this breakdown should be shared with. There are three levels of breakdown and the details of lower levels should never be revealed to higher levels: 1. The "business" level. There are no "tasks". There are only needs and desires. Things like "a user can log in and press a button". These should not be broken down further than the smallest unit of deliverable value. In this example, there's n…

Can you elaborate on why we wouldn't share the carefully estimated project plan breakdown with Level 1? I'm not disagreeing, just curious - one would think that with doing all the work to achieve a solid project plan breakdown and Gantt charts and such, it would behoove you to express this to management who is salivating over tangible examples of progress... I understand we don't want to show technical to non-technical, but part of the good project plan is the fact that we can show a roll-up of the tasks, so the abstraction is visible. It's hierarchical.

Re: Breaking down tasks

#63

Post by ncphillips »

Scarblac wrote: post #43

I've also done this a lot, as has everybody. My experience is that there are two problems. One, it turns out I never ever end up doing the actual steps as I planned to. After a few I have new insights, realize I forgot something, see an easier way, I don't know -- the plan is never followed. The other is that I really hate working like this because it seems all the creative effort of thinking about how to make someth…

> I never ever end up doing the actual steps as I planned to

I do the GTD thing of only thinking about the _next_ action, not trying to think of every action.

Re: Breaking down tasks

#64

Post by chrisweekly »

Scarblac wrote: post #43

I've also done this a lot, as has everybody. My experience is that there are two problems. One, it turns out I never ever end up doing the actual steps as I planned to. After a few I have new insights, realize I forgot something, see an easier way, I don't know -- the plan is never followed. The other is that I really hate working like this because it seems all the creative effort of thinking about how to make someth…

Tangent: I can't recall where I first heard "plans are worthless, but planning is essential", but there's definitely some truth in it.

Re: Breaking down tasks

#65

Post by mlrtime »

chrisweekly wrote: post #64
Scarblac wrote: post #43

I've also done this a lot, as has everybody. My experience is that there are two problems. One, it turns out I never ever end up doing the actual steps as I planned to. After a few I have new insights, realize I forgot something, see an easier way, I don't know -- the plan is never followed. The other is that I really hate working like this because it seems all the creative effort of thinking about how to make someth…

Tangent: I can't recall where I first heard "plans are worthless, but planning is essential", but there's definitely some truth in it.

Certainly holds true for having a baby.

You can plan all you want and it is essential... however you'll quickly find out that most of your plans are in your newborns' hands.

Re: Breaking down tasks

#67

Post by zarathustreal »

fmbb wrote: post #61
arnorhs wrote: post #60

Earlier quoted context omitted.

Whenever you talk about breaking down tasks, estimations etc, those usually are for multi-person teams, and/or projects that have some specific budget or something. Of course if you are exploring or building your own projects and/or don't have any other accountability, you wouldn't start planning that.. unless you are really into planning in and of itself. But as soon as you have a boss and the boss asks "how long? w…

> But as soon as you have a boss and the boss asks "how long? who does what? where do we start?" - you have to have some framework. Why? Does it work? Is it productive? Is it better than not doing that?

Suppose it doesn’t work, it’s not productive, and it’s worse than not doing it.

You still have a boss asking these questions. Any answer you provide constitutes a framework.

Re: Breaking down tasks

#68

Post by crucialfelix »

chrisweekly wrote: post #64
Scarblac wrote: post #43

I've also done this a lot, as has everybody. My experience is that there are two problems. One, it turns out I never ever end up doing the actual steps as I planned to. After a few I have new insights, realize I forgot something, see an easier way, I don't know -- the plan is never followed. The other is that I really hate working like this because it seems all the creative effort of thinking about how to make someth…

Tangent: I can't recall where I first heard "plans are worthless, but planning is essential", but there's definitely some truth in it.

Dwight Eisenhower, who also created The Matrix.

Re: Breaking down tasks

#69

Post by alkonaut »

The biggest problem I have with splitting tasks is reluctance to do duplicate or unnecessary work. Breaking down tasks into smaller tasks means you must do duplicate work. The trick is to minimize it.

If you try to make no unnecessary work, you'll end up having to do everything at once.

Example: you want to refactor a program with two modules A and B where B depends on A. The least wasteful way of doing it is to refactor both modules together. But it's also the riskiest and hardest to estimate.

The broken down way is to refactor A and adapt B so that it works with the refactored A. After that you would refactor A, which would then risk making the adaptation effort very short lived.

If you want to do zero throwaway effort, you often can't break down the task. I have 20 years of experience and I still often find myself reluctant to do throwaway/temporary job in order to divide work. Instead I find myself doing multi-week efforts with zero yaks left unshaved.

Re: Breaking down tasks

#70

Post by ssivark »

rolisz wrote: post #25
hnaccountme wrote: post #24

Software development cannot be managed like this. This sort of task break downs come from classic management training. The problem most people are unaware of is software development is more a creative activity than anything else. Yes there are serious technical aspects to it but since the problem is virtual and not bound by any real world limitations, like how civil engineering would be, there isn't one optimal solut…

You'd be surprised how much creative tasks like 3D modeling and creating artwork can be broken down into tasks that are very well defined and can be estimated quite correctly.

If that’s the case, what makes the work “creative”? (It’s possible two sets of people use the term to mean two different things)
Post reply on HN