Most active commenters
  • rrr_oh_man(4)
  • nmstoker(3)
  • regularfry(3)
  • replyifuagree(3)

←back to thread

388 points replyifuagree | 35 comments | | HN request time: 1.75s | source | bottom
1. nmstoker ◴[] No.37966119[source]
I get the point, and with irresponsible parties (as is fairly widespread in most companies) there's a real risk here.

However the analogy of a meteorologist seems poor as that job is focused on predicting the weather - the typical dev is focused on operating in that weather and comparatively inexperienced in predicting with great accuracy.

What's frustrating as a stakeholder is ludicrous estimates, which don't even start with the work time, let alone end up with a realistic duration. This is particularly true (and frustrating) at the micro task level, an area I'm often requiring items that take at most 30 minute to complete and are usually things I could do in less time if only I had access... You get a weeks long estimate back, even when it's incurring a serious cost in production and falls in the drop everything category (which obviously one wants to avoid but does come up). I get that none of those 30 minute tasks will take 30 minute alone as there's testing and documentation to add but the more bs level the estimate, the more it damages the trust relationship.

replies(9): >>37966150 #>>37966194 #>>37966480 #>>37966493 #>>37966648 #>>37966946 #>>37967117 #>>37967327 #>>37968617 #
2. Aeolun ◴[] No.37966150[source]
To some extend, but there’s tasks that I could do in 30m in a company with 15 employees that I have still not accomplished after 2 months in our 15k employee enterprise.
replies(3): >>37966496 #>>37966780 #>>37966920 #
3. regularfry ◴[] No.37966194[source]
I think there's an important detail you might have left out of your 30 minute example: are you asking for how long the effort on the specific task will take, or what the time gap will be between right now and the moment it's delivered? Because in almost all teams both are dominated by the task waiting for something, but in the latter case it's especially true. Actual hands-on-keyboard time is usually a rounding error compared to coordination and scheduling. Unless a team has put hard work into unintuitive ways of working, the average ticket will spend grossly more time waiting than actually being worked on. Not only that, but the team will be completely blind to the imbalance, and won't realise it matters.
replies(2): >>37966822 #>>37968574 #
4. mannykannot ◴[] No.37966480[source]
I have never had the misfortune to work in a place even remotely that dysfunctional, and I feel that there must be a considerable history behind it becoming that way.
5. orwin ◴[] No.37966493[source]
Don't ask for 30 minutes tasks unless you have to (it's breaking the prod or something), it's inefficient for everyone involved.

I'm in a team with a lot of leeway. No one is counting my hours, no one external look at our productivity, but when we're needed, we don't have time to polish our code. When i have a '30 minute' task identified, I put it in our morning review, and ask if something adjacent should be done while I'm on the subject. If there is nothing, I'll still take the full day (except if it's a project I know really well, in that case I take half), and take half a day to skim the code, and another half to update it (small comment, version upgrade, code improvement, renaming variables).

Push your IC to do the same. Imo it's more time efficient, the new-ish IC use that time to learn the older code, and in the end you will have less legacy issues (unless you make a big change).

replies(2): >>37966842 #>>37968866 #
6. wkat4242 ◴[] No.37966496[source]
This so so much.

Some tasks take me 10 minutes but it takes me half a day to jump through all the hoops that our colleagues have thrown up. Excel approval sheets, annoying proxies with SSL inspection (try configuring all that in multiple docker containers), having no access to actually configure what I need to do so I constantly have to put in tickets to other teams..

The worst thing is when they then outsource the work and ask us why they can do it so much faster.... :X

7. makeitdouble ◴[] No.37966648[source]
Ludricrous estimates are usually a symptom of other organizational quirks.

I'd compare it to the military's $435 hammer [0], from the outside you'd think it makes no sense, but that's the logical end of a series of processes that all somehwat made sense on their own.

A common issue I've seen is devs having to put their head on the chopping block when making estimates. After the second or third time they get seriously punished for blowing pat deadlines, they'll happily go with around 10 times their own estimate. But there's so many other incentives where going with a "done in 2h" estimate is just a bad decision.

[0] https://www.washingtonpost.com/blogs/wonkblog/post/the-penta...

replies(1): >>37966725 #
8. dahart ◴[] No.37966725[source]
Oh wow, I had no idea the story of the $600 hammer was still around. This has been a talking point for like 40 years now, and it was a different number when I was a little kid. Turns out the story had been debunked at least 13 years before the article you posted was written, and is 25 years old now. The military never paid hundreds of dollars for a hammer, someone just averaged a bunch of financial R&D overhead and then someone else took the numbers out of context and spread it around. https://www.govexec.com/federal-news/1998/12/the-myth-of-the...
replies(2): >>37966861 #>>37967437 #
9. briHass ◴[] No.37966780[source]
Large orgs almost become like a bloated government in that way: groups start to construct little fiefdoms with rules and policies that are ostensibly constructed to improve quality. However, those rules end up becoming bludgeoning tools used by nefarious actors in those groups.

The real problem is that nobody ever steps back and asks: are all these rules actually helping to improve quality of the software. Is the cost of the reduced velocity and overhead actually worth it in the end.

Then, the org does layoffs and all that policy is still in place without the necessary people to supported the bloated workflow.

replies(2): >>37966834 #>>37970883 #
10. rrr_oh_man ◴[] No.37966822[source]
> Unless a team has put hard work into unintuitive ways of working, the average ticket will spend grossly more time waiting than actually being worked on.

What do you mean by "unintuitive ways of working"?

replies(1): >>37976301 #
11. rrr_oh_man ◴[] No.37966834{3}[source]
> are all these rules actually helping to improve quality of the software

While I agree with your sentiment, high quality software (and: what is high quality, anyway?) is not necessary the goal of an enterprise.

replies(1): >>37970790 #
12. rrr_oh_man ◴[] No.37966842[source]
Any downsides to this approach, from your experience?
replies(1): >>37968489 #
13. makeitdouble ◴[] No.37966861{3}[source]
The averageing of the numbers is also the take of the article I checked, but to me it stays a good example of the phenomenon: that contract with no itemized prices and a high average price per item fits inside a procedure that probably isn't bad in itself, but gets turned into spicy headlines.
14. Veuxdo ◴[] No.37966920[source]
Linear scaling is more the exception than the rule, no? And it not just for "tech" either: it's unlikely you could learn the names of 15k employees in 2 months, for instance.
15. xorcist ◴[] No.37966946[source]
> 30 minute to complete and are usually things I could do in less time

Why don't you? Surely there are ways of granting the required access in your organization?

If the answer is something akin to "not my job", then you have an organization that values intercommunicating pieces each with strict responsibilities. It should be expected that communication completely dominates output performance.

If properly tuned, such organizations can achieve good quality, and if the duties are well specified, also great throughput. But they will never have low latency, as turnaround time is sacrificed for other tings.

The example of a week long estimation for a trivial task is pretty much expected then. In a fully booked schedule, any new task is not likely to be scheduled for weeks. If that task then requires the attention of more than one person, because of the above fine grained responsibilities, those turnaround times really start to add up.

If that's not a good fit for the job at hand, the organization is just not suited for the task.

16. kayodelycaon ◴[] No.37967117[source]
I feel this pain, I really do. I want to turn around to fix quickly.

The problem is unless you have fully-automated continuous deployment, 30 minutes is not 30 minutes. That 30 minute task needs to be vetted to ensure it doesn’t affect other departments, then it needs to be scheduled, announced, and deployed, which may involve 2 to 3 other people. As a scheduled task it’s closer to 2 hours across multiple people. As a hotfix or support ticket, it which becomes 4~6 hours of lost productivity for a hotfix if there is any kind of QA process beyond automated tests.

Add in six other people asking for “30 minute tasks” that have unknown impact on other people in the company and nothing will ever get done.

My team has workflows for hotfix changes, but it truly needs to be a drop-everything emergency that stops the company from operating. For all but the blindingly obvious, a department, head or higher, must make the request.

Not being able to turn around every urgent ticket is far less damaging than having a fix for one person cause problems for several other people or not delivering on large strategically-critical projects.

replies(1): >>37969531 #
17. replyifuagree ◴[] No.37967327[source]
Yep, these days I tend suss out the estimate the person is looking for because the relationship is actually more important to my career longevity. I mean, the estimate is very likely wrong anyway, so they might as well be happy for a bit!

This works because almost never is the true scope of the work known when the ask is made, so it is usually pretty easy to say later "hey, blah blah blah wasn't taken into account for the estimate." Having a good relationship from step one makes it pretty easy to carve out the extra time.

There are some more lizard brained people who play hardball, but as long as I was nice in step 1, my VP handles them. Not sure what I would do if I didn't have a decent VP!

replies(1): >>37968894 #
18. arh68 ◴[] No.37967437{3}[source]
I would not say it has been "debunked".

The stories are real; they're not all "accounting misunderstandings" or what have you.

[1] https://www.airforcetimes.com/news/your-air-force/2018/10/23...

19. orwin ◴[] No.37968489{3}[source]
I only have 10 month working like this, but yes. More linked to the code than to the approach, but sometimes I become easy to get lost on the 'I also need to fix this' and deliver the code _really_ late. My way of dealing with it is simple: at 4pm (I usually stop at 6), I take a 15 minutes break, talk with people (remote or not), make some tea and stuff, recenter myself. Then I check what can be merged into master before 6, scrap the commits I won't use, rebase the rest into one or two commits, then push and ask for review (once it was the '30 minute task' that pulled a lot of other shit, in this case I stopped and called the team lead/PM to redefine the card).

Then if I still have time I do reviews, administrative work and probably end the day there. The nature of our team make that time management suitable.

20. Groxx ◴[] No.37968574[source]
Yeah, the 30 minute tasks would more frequently be quick if there was room for them.

You can have agile flexibility or you can have lists of tasks that you have attempted to minmax that people are tracked to finish. Not both. Flexibility costs significant down time, if you're not being given it then you're not being allowed to be flexible.

replies(2): >>37969139 #>>37976462 #
21. replyifuagree ◴[] No.37968617[source]
I promise you what you are experiencing is a management problem, not a dev problem. Devs absolutely love executing on creating easy to code software solutions to well defined problems. Many of us will work the weekend on that kind of work just to get the dopamine rush.
22. nmstoker ◴[] No.37968866[source]
Understood. I never do unless it were breaking prod or breaking major business processes.

Regular approaches, avoiding firefighting are essential to steady, stable states.

replies(1): >>37968884 #
23. nmstoker ◴[] No.37968884{3}[source]
Sadly the need comes up too often.
24. c0pium ◴[] No.37968894[source]
> Not sure what I would do if I didn't have a decent VP!

Learn how to actually do your job?

It’s always interesting to see toxic positivity painted in such a favorable light. Very glad I don’t work with you.

replies(1): >>37969835 #
25. Mc91 ◴[] No.37969139{3}[source]
Correct. If management told our team that our performance was based on getting 2-3 planned features out this quarter, and we've been minmaxed to fill our schedules, and there's a hiring freeze and one team member just left - then we have no room for some "30 minute" (which is much more than 30 minutes for us) request. Also, management has told us that our performance reviews are based on whether we got these 2-3 planned features done within a very aggressive schedule, not your "30 minute" request - so it is management who has said this is of minimal importance, not us.
replies(1): >>37970115 #
26. iimblack ◴[] No.37969531[source]
This is way too true. So many quick changes or fixes at my company have caused incidents, confusion, and more. That 30 minute fix quickly balloons into days of work and unhappy clients.

Even things that don’t blow up on those have so many hidden costs people don’t think about.

27. replyifuagree ◴[] No.37969835{3}[source]
If you are like most business people I've worked with, you love my complicity.
replies(1): >>38018635 #
28. ◴[] No.37970115{4}[source]
29. Aeolun ◴[] No.37970790{4}[source]
Faster development almost invariably is though. Everyone wants to be able to say their project got done on-time and according to spec.
30. pixl97 ◴[] No.37970883{3}[source]
Even this isn't really looking at the problem correctly.

If your two man organization if one person steals the source code or slips in some back door into the code, it should be somewhat obvious who did it.

On the other hand in that large enterprise someone doing the same could lead to an international incident. And with that many people you are going to have nefarious actors at some point and you need to think about how to minimize their damage.

It's likely you're falling into the same trap of understanding why Chestertons fence was put up in the first place.

replies(1): >>37971102 #
31. briHass ◴[] No.37971102{4}[source]
The problem is, the whole mess becomes so abstracted away from the real goal: shipping software to customers and making money. Government can get away with it, because they're the only game in town, but a company doesn't have the luxury of operating with a crippling level of inefficiency for long.

Whatever 'deal with the devil' that existed when the fence was erected may no longer be relevant or worth the overhead, but the policies live on. There may even now be individuals who's jobs are now directly related to enforcing/implementing the policy, and they have an interest in perpetuating it at any cost.

32. regularfry ◴[] No.37976301{3}[source]
Here's a relatively small example: if you want to minimise lead time (which is almost always true) then one thing you don't want is for potentially releasable work to sit waiting for anything. That includes code reviews, if you have them on the route to production. So the right thing to do is usually for a PR being ready for a code review to be a drop-everything event for the person who's going to review it. As in, whatever you're working on right now, context switch out and do whatever is needed to get that code either over the line or bounced back ASAP so the person who wrote it doesn't context switch out.

This idea gets a lot of pushback because we have it ingrained (not unfairly, either) that context switches are expensive for the reviewer. But the safe assumption is that they're less expensive than delaying another piece of work that's already got a lot of embodied but unrealised value.

The intuitive assumption is that person waiting on the code review can pick up another piece of work and make a start on it so they're kept busy, but that falls into the trap of having too much work in progress. The result is then (usually) that the returned code review is now waiting for whatever they picked up. This is one reason why the intuitive way of working tends to having throughput that's barely ok, and latency that borders on ridiculous.

replies(1): >>37981567 #
33. regularfry ◴[] No.37976462{3}[source]
This is really a case of over-utilisation. If you want a 30 minute task to be reliably out of the door in a time that's even of the same order of magnitude, the team has to be operating at 80% utilisation or less which, if it's the usual story of The Backlog That Never Ends, happens approximately never.
34. rrr_oh_man ◴[] No.37981567{4}[source]
That's an interesting take!
35. c0pium ◴[] No.38018635{4}[source]
I get people like you fired.