Sunk cost fallacy can be a problem if you spent sufficient time breaking down tasks for a big project. You may not want to pivot and re breakdown
Breaking down tasks
11–20 of 118 posts
Re: Breaking down tasks
#12Maybe 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…
> 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.
Re: Breaking down tasks
#13Sunk cost fallacy can be a problem if you spent sufficient time breaking down tasks for a big project. You may not want to pivot and re breakdown
Isn't it more likely that you can catch yourself during the planning phase if the amount of work being estimated exceeds your budget? That seems much cheaper and easier to pivot from than if you were to make that realization halfway through your implementation.
Re: Breaking down tasks
#14> Delivers change because, in a work context, a task only “matters” if something is different because of the work. I think maintenance tasks may require more effort / more expansive qualification when it comes to the meaning(s) of "something is different". I think the topic of "breaking down tasks" could very well be its own book genre or even podcast genre. My experience with self-help and organization titles has be…
The problem I have with task breakdowns is you get way too much engineer overconfidence - i.e. there is literally no task which is less then an entire day's effort, in practice. There's about 6 usable hours in a day - I've watched people confidently bid they'll get something done in "half a day" but when you point out that's about 3 hours, suddenly they're way less sure about that number - or offended. Then 3 days later they're still working on it.
Re: Breaking down tasks
#15Breaking down work works great until the breakdown is unknowable. Things like research, that require creative experiments to POC things that are not known apriori. That’s when task breakdown breaks down.
Also when management sees what should be a POC or research as a deliverable they start promising to higher ups and other teams. I’ve developed the habit of doing most of my POC work behind closed doors and telling no one. If it works great, I can release it. If it doesn’t, I can kill it and move on without having to eat crow, or get told I need to figure out a way to make it work after I’ve seen it’s not wise to continue.
Re: Breaking down tasks
#16I don’t know. I think that’s the main truth about software engineering. Maybe an open source version of that Streak app exists and OP is re-inventing the wheel. I think the brain doesn’t like task list. It may be pleasant to do, but most of entrepreneurship or coding is exploring. And a task list blocks you from exploring.
I'm curious: if you hired a contractor to, I dunno, paint your walls, would you accept "I don't know" as a time frame or price quote? If not, what's different about software development that makes "I don't know" a reasonable answer in our profession?
Re: Breaking down tasks
#17> Delivers change because, in a work context, a task only “matters” if something is different because of the work. I think maintenance tasks may require more effort / more expansive qualification when it comes to the meaning(s) of "something is different". I think the topic of "breaking down tasks" could very well be its own book genre or even podcast genre. My experience with self-help and organization titles has be…
The problem I have with task breakdowns is you get way too much engineer overconfidence - i.e. there is literally no task which is less then an entire day's effort, in practice. There's about 6 usable hours in a day - I've watched people confidently bid they'll get something done in "half a day" but when you point out that's about 3 hours, suddenly they're way less sure about that number - or offended. Then 3 days la…
Sometimes it is not overconfidence but a side-effect of management interference & second-guessing the estimates.
In this case engineers give an estimate of what they think management wants to hear and not the actual time it takes. It happens if they are frequently asked to reduce their estimated time to within management expectations.
To deal with this, you need to bargain with them in the opposite direction to make sure the estimates are realistic.
Re: Breaking down tasks
#18Sunk cost fallacy can be a problem if you spent sufficient time breaking down tasks for a big project. You may not want to pivot and re breakdown
> Sunk cost fallacy can be a problem if you spent sufficient time breaking down tasks for a big project. You may not want to pivot and re breakdown
Similarly, if you don't plan enough, and get far enough into a small project, you don't change your approach because of the sunk cost fallacy.
Re: Breaking down tasks
#19> Delivers change because, in a work context, a task only “matters” if something is different because of the work. I think maintenance tasks may require more effort / more expansive qualification when it comes to the meaning(s) of "something is different". I think the topic of "breaking down tasks" could very well be its own book genre or even podcast genre. My experience with self-help and organization titles has be…
The problem I have with task breakdowns is you get way too much engineer overconfidence - i.e. there is literally no task which is less then an entire day's effort, in practice. There's about 6 usable hours in a day - I've watched people confidently bid they'll get something done in "half a day" but when you point out that's about 3 hours, suddenly they're way less sure about that number - or offended. Then 3 days la…
Estimating time for a task is it's own skill. And, of course, the danger is in the task being insufficiently specified, leading to unknowns.
Cook lunch, estimate 30 minutes. Task starts, oh wait, cupboard is bare, need to go shopping.
Over a long career I've found that you do the best estimate you can with the information provided. Then multiply by 4. Sounds extreme, but you're still likely to be short a bit.
Equally, for estimates, I like to first estimate the number of data tables. That's a good factor to bring in to the rest. A system with 10 tables, 100 tables, 200 tables and so on "magnifies" the task list.
"Build reports" has a proportionate number. 10 tables might mean 5 reports. 100 tables might mean 50.
Building reports might be easy, but the number of them means time is needed.
Re: Breaking down tasks
#20Breaking down work works great until the breakdown is unknowable. Things like research, that require creative experiments to POC things that are not known apriori. That’s when task breakdown breaks down.
Also when management sees what should be a POC or research as a deliverable they start promising to higher ups and other teams. I’ve developed the habit of doing most of my POC work behind closed doors and telling no one. If it works great, I can release it. If it doesn’t, I can kill it and move on without having to eat crow, or get told I need to figure out a way to make it work after I’ve seen it’s not wise to cont…
I'm jealous that you have such flexibility at work that you can do POCs behind closed doors!