Hacker News Reader

Comment by itsgrimetime | Hacker News Reader

Maybe I’m just lazy/undisciplined/a cowboy but having to break things down into “pointable” tasks feels like busy work just so management can “see” progress.

I mean, thinking through a problem you’re trying to solve before starting makes sense, and having rough milestones is important - but a majority of the time there’s so many unknown unknowns that fully breaking it down is totally useless, if not impossible.

If I spent the same amount of time it took me to break a project down just working on figuring out a solution or building it, it’d get done way sooner. At least, that’s how it feels.

View on HN

> feels like busy work just so management can “see” progress

Lot's of people feel like this. I usually come at it a different way - we're trying to estimate effort to see if we want to attempt building it in the first place. Assisting with the cost-benefit question if you will. That's the first reason.

It can also be extremely beneficial to the team, particularly when working with less experienced folks. You can farm out a lot of the work and parallelise the task.

I suspect Jacob didn't do much of this breakdown when implementing his streak app, which is why he recurses in an illustrative way.

Ignoring management part, one place where I have found breaking down to be helpful is when I have to work on some thing which I am not terribly motivated todo (say it is boring, lethargy, or it looks too daunting). In such cases I have found it useful to break down to smaller tasks and keep completing each of them which in turn generates a momentum to continue, as I have been able to make some progress from a situation where I was essentially in a deadlock (or was lethargic to work on).

I mostly disagree with you if you work in a "standard" company - it's usually "make a form" or "move data / do some other CRUD". These tasks don't generally have that many unknowns.

It's absolutely valuable for managers to be able to estimate velocity as well, though the problem is that they really do stop understanding "we are not sure" once you spoil them.

I am a consultant too, so it's critical for me to say "we are delivering this, in this much time", even though we are "agile".

Reply on news.ycombinator.com