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

41–50 of 118 posts

Re: Breaking down tasks

#41

Post by makeitdouble »

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.

I think it would fall down the same lines if you required a coherent world and high quality for each of the models you create.

That would mean redo models that don't fit the whole piece, endless tweak some models that are really difficult to get right, sometimes do swiping changing across all the parts because as a team you realize something is off etc.

The balance will be between delivering something within a time frame, and delivering the quality that was requested/expected.

Re: Breaking down tasks

#42

Post by Scarblac »

XorNot wrote: post #14
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…

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…

But sometimes I see a task that would take about a day... and then people insist on breaking it down in four parts!

Then they take about a quarter day each, provided the same person does all four simultaneously. Or about a day each if you give them to different people.

Re: Breaking down tasks

#43

Post by Scarblac »

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 something is put in the first part. And then, the rest is still most of the work, but it's the really boring part. It's much more fun (and therefore faster, and resulting in better work) to spread the creativity and the boredom out more equally.

The two are probably related, and it's not inconceivable that I have ADHD.

Re: Breaking down tasks

#44

Post by Cyphase »

xboxnolifes wrote: post #31
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?

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

If your job involved _only_ putting up or modifying API endpoints that involved querying a single SQL database, you could automate at least a good chunk of that. Maybe all of it.

How long would it take to build a system to automate API endpoints that query a single SQL database? It depends.

Re: Breaking down tasks

#45

Post by suslik »

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 am somewhat like that myself. I do formulate a plan and break down tasks in advance, but I give myself an absolute right to change and modify it at will whenever new ideas come to light or just because I'm feeling like it.

Re: Breaking down tasks

#46

Post by heisenbit »

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.

The difference is that you break down software into smaller and smaller bits and then find a small bit that needs data from a far away small bit. I suspect this happens less with mechanical systems.

Re: Breaking down tasks

#47

Post by michaelt »

leetrout wrote: post #26
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…

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

> Do you have more examples of companies that are not feature factories?

Actually, none of them are. They're just managed as if they were.

In a factory, you can literally have a machine that stamps out 1000 widget blanks an hour and if the operator does an hour of overtime, that's an extra 1000 widgets produced that day.

You've got your workers on 8-hour shifts and sales signs a contract to deliver 8,500 widgets per day? Then you know right away you're going to need 10-hour shifts, or regular overtime, or a second 8-hour shift, or a second machine, and you can figure out how much each of those would cost, and whether you've got enough car parking for the extra workers.

Whereas in software, your feature factory produces ???? per hour, sales promises customers ???? and an hour of overtime achieves ???.

Re: Breaking down tasks

#48

Post by Rygian »

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…

> the plan is never followed

The plan not being perfect and prescient is part of the plan.

Next time you plan for same or similar activity, your future plan will be better.

The Project Managers even have a mantra: "fail to plan is plan to fail."

Re: Breaking down tasks

#49

Post by n4r9 »

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…

Do you have any pointers for guides about how to implement this sort of methodology in software-based R&D? I'm currently in a small, partly research-focused team as part of a larger tech company, and it's proving a struggle to align our work with the rest of the dev squads who do all their work in 2-week sprints with max-2-day tasks. I'd love to better understand how research teams tackle this problem in other companies. It would be amazing if I could present an alternative strategy to management that's worked elsewhere.
Post reply on HN