Comment by tareqak | Hacker News Reader

Comment by tareqak | Hacker News Reader

> 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 been that the activity of breaking down tasks is a sort of known primitive human operation that many authors assume their readers to have. However, my own personal experience and the accounts of others I have heard while participating in group sessions is that breaking down tasks can be very difficult and provoke emotions of avoidance and despair.

The most broadly relevant advice that I have come across when it comes to breaking down tasks is to keep breaking things down until I am 90% certain that I can successfully complete the task. The certainty here would vary on how much self-confidence an individual has and their risk tolerance, so some people may break down tasks to 70% certainty of success.

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.

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.

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.

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.

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.

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.

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

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.

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.

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

Reply on news.ycombinator.com