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

31–40 of 118 posts

Re: Breaking down tasks

#31

Post by xboxnolifes »

jacobian wrote: post #16
hartator wrote: post #2

I 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?

> what's different about software development that makes "I don't know" a reasonable answer in our profession?

The seemingly infinite amount of variations in software tasks and the ambiguity of the requirements? If my job involved only putting up or modifying API endpoints that involved querying a single SQL database, I'd get quite good at that and be able to tell you with very good accuracy how long an endpoint would take to put up.

Just as if I painted many walls before, I could reasonably tell you how long painting a wall would take based on the surface area, height, and amount of non-wall obstructions. Also, contractors tend to be their own salesmen, so just because they speak confidently, doesn't mean they are. It's not like contractors are universally famous for being on-time and underbudget.

Re: Breaking down tasks

#32

Post by kvmet »

Jtsummers wrote: post #21
jacobian wrote: post #16

Earlier quoted context omitted.

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?

Software development isn't (universally) a painting type task. In painting a room, the painter can estimate (by measuring) the amount of paint needed, they know from experience the time to acquire a particular color (if it needs to be mixed or can be bought readymade) in a particular volume, they know how long it takes to paint (they've done it many times before), how long to dry, and how many coats are needed for th…

This kind of thing destroys freelance devs who don't have context.

Customer: "Hi we need this small change." Dev: "No problem! Here's a quote for 4 hours"

Ignoring that 4 hours is probably less than the effort to consult, estimate, generate and process contracts, bill, do taxes... Then the customer comes back and asks for a revision which will at least require a Change-Order or a separate PO.

To some extent the overhead should be covered under labor burden but the reality is that in a sole proprietorship YOU are also the person doing the labor that is within the definition of "labor burden". It adds up extremely fast.

A million dollars would be a windfall if it landed in my checking account. On a development project with hardware and more than one dev it might as well be dust in the wind.

Re: Breaking down tasks

#33

Post by 8n4vidtmkvmk »

XorNot wrote: post #23
bruce511 wrote: post #19

Earlier quoted context omitted.

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…

This is close to my rule - whatever I think, multiply by 3. Then multiply by 3 if it includes any amount of "get another team, under a different manager, to do something". It's been accurate more times then I care to think.

My current project estimate is 1 year. I'm afraid if I need to multiply that by 3.

Re: Breaking down tasks

#34

Post by begueradj »

tareqak wrote: post #9

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

Yes, maintenance tasks consume more resources. After all, that's what the classic SDLC methodologies state.

Re: Breaking down tasks

#35

Post by MrOxiMoron »

devsda wrote: post #17
XorNot wrote: post #14

Earlier quoted context omitted.

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…

this, the number of times I've heard: I can't sleep those estimates to the customer. How is that a me problem? I don't care how you sell it, just know that my estimate is pretty accurate on how much time we need to build it.

And also don't expect us to work 8 hours a day doing tasks.

Re: Breaking down tasks

#36

Post by sateesh »

itsgrimetime wrote: post #8

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…

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

Re: Breaking down tasks

#37

Post by stana »

hackerlight wrote: post #30
leetrout wrote: post #26

Earlier quoted context omitted.

> But since most companies are managed as factories, all the processors will ultimately create a very limited product targeted at a specific customer. Do you have more examples of companies that are not feature factories? It seems the entire industry has adopted this pattern.

Bell Labs? Changing the topic from software development to R&D: the granular task oriented view is generally not good for greenfield research endeavours. It's a form of premature optimization. You're calcifying the search space and reducing flexibility to pivot immediately based on expert intuition and hunches. That being said, a coarse task orientation is necessary to keep people vaguely pointed in the right directi…

Interesting you mention 'intuition'. I feel it is a big part of software development as you gain experience and it flows through as you are doing the work and would be tough to plan for. Also remember one of my colleagues complaining after work 'code just not flowing freely today'. And then there are times when you feel you are in the zone, which would definitely be the creative element.

Re: Breaking down tasks

#38

Post by throwaway346434 »

teeray wrote: post #6

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

Nah, that's easy to solve.

"spend 3 hours on investigating X, 3 on Y, 3 on Z"; and then have a planning session about what to do next.

You have 4 outcomes - the first one solves it, the second, the third or none.

If it is solvable with mild effort, you have a 50% chance of solving it by attempt 2/6 hours.

Re: Breaking down tasks

#39

Post by CRConrad »

hackerlight wrote: post #30
leetrout wrote: post #26

Earlier quoted context omitted.

> But since most companies are managed as factories, all the processors will ultimately create a very limited product targeted at a specific customer. Do you have more examples of companies that are not feature factories? It seems the entire industry has adopted this pattern.

Bell Labs? Changing the topic from software development to R&D: the granular task oriented view is generally not good for greenfield research endeavours. It's a form of premature optimization. You're calcifying the search space and reducing flexibility to pivot immediately based on expert intuition and hunches. That being said, a coarse task orientation is necessary to keep people vaguely pointed in the right directi…

> Bell Labs?

Too bad that's pretty much the only such example that has been touted since... The 1960s, is it? And that it was, IIRC, recently either shut down or announced to be shut down sometime soon.

Thus, using this as an example seems, if anything, to illustrate not that "there are too!" but "there are dwindingly few".

Re: Breaking down tasks

#40

Post by Ma8ee »

bruce511 wrote: post #19
XorNot wrote: post #14

Earlier quoted context omitted.

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…

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

Me myself rely on Hofstadter's Law: It always takes longer than you expect, even when you take into account Hofstadter's Law.

Post reply on HN