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

21–30 of 118 posts

Re: Breaking down tasks

#21

Post by Jtsummers »

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?

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 the type of surface.

Now, ask them to paint a mural instead. The estimates will change, they'll probably give you a broader range instead of being able to estimate almost down to the minute (and being off by no more than an hour or two) like someone just painting walls (with a known environment, surface type, and paint material).

Does the mural need to be designed? Are the desired qualities of the mural well-specified or will there be a series of back and forths? Maybe a set of prototypes (sketches) so that you can refine your requirements. At that point, the estimate for the total task (design and paint a mural, or design and develop a software application) becomes far less clear.

There are certainly programming tasks which are closer to the paint-a-wall task which are much easier to estimate reliably, but they're far from the only thing people in this field work on.

Re: Breaking down tasks

#22

Post by bruce511 »

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…

Managers are typically squeezed between the person who "wants the project done, and sets the budget" and the technical folk doing the work.

Kinds like the architect sitting between the client and the building contractor. The client wants the moon, on a low budget, and wants it completed yesterday.

A strong manager understands their role, and the constraints (time, money) of the system and is able to find compromise where necessary. They're there to guide the owner, and at the same time monitor the workers.

Of course the vast majority of middle management are not strong. They see their role as passing on orders from on high. The boss is the customer, and the customer is always right. So their only part is to demand more from the workers.

Strong tech workers understand what the manager needs. Good time estimates. Limited budget. The manager needs to be passing accurate data upstream. Bad workers ignore reality, tell a manager what he wants to hear, and just do their thing. Not realising that they (the programmers) will be the ones thrown under the bus ehen it goes tits up. (Another sign of bad managers is to blame the underlings.)

Good managers, working with good techies, is a match made in heaven. Together they deliver accurate estimates, with plenty of contingency time. Together they decide what features are necessary, and what can be canned. If you are in this dynamic, count yourself lucky.

If you are a good manager working with crap staff, well, that's unlucky. But at least you can turn them over. If you are a good tech working with a crap manager (which I suspect is most of us) then, well, I guess the only options are to stay, or quit.

Bad managers can be made better with explanations though. The more they understand the constraints, the better equipped they are to argue the point with the customer.

Re: Breaking down tasks

#23

Post by XorNot »

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…

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.

Re: Breaking down tasks

#24

Post by hnaccountme »

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 solution. Trying to define the solution before the problem has been properly examined would only limit the final output. Most of the exploration only happens when people actually start coding.

Not having a well defined final output and time is not very relevant for software, mostly because there is no per unit cost. Most managers do not realize this is they are not from a software engineering background. A versatile product can be sold to many different customers without additional development costs.

But since most companies are managed as factories, all the processors will ultimately create a very limited product targeted at a specific customer. What the big tech companies have avoided is this .

Re: Breaking down tasks

#25

Post by rolisz »

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.

Re: Breaking down tasks

#26

Post by leetrout »

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.

Re: Breaking down tasks

#27

Post by beryilma »

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?

Contractor horror stories are actually very common. They may not actually say to you "I don't know", but big delays in contractor jobs happen all the time. I would argue that software engineers are at least trying to be more honest about the unknowns of the work unlike some sleazy contractors.

Re: Breaking down tasks

#29

Post by hyperthesis »

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…

Similar: the more uncertainty, the further I break it down.

This has been amazingly accurate for time estimates - in aggregate... Individually, they are wildly inaccurate.

So... they are probability estimates. Over many events, they even out.

Re: Breaking down tasks

#30

Post by hackerlight »

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.

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 direction. The best resolution (time horizon) for task orientation depends on what you're doing.

Post reply on HN