Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

"No, it's less effort than that"

smartguess.is

Post reply on HN
Print view View original

111–120 of 388 posts

Re: "No, it's less effort than that"

#111

Post by mannykannot »

nmstoker wrote: post #69

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

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.

Re: "No, it's less effort than that"

#112

Post by pydry »

regularfry wrote: post #94
pydry wrote: post #83

Earlier quoted context omitted.

>Relative sizing is still an estimate. Not one which would attract any pressure.

If you're doing Scrum, then you might have noticed that the Scrum Guide considers the contents of a sprint to be a "commitment" on the part of the team. That "commitment" is usually built by taking the number of story points delivered last sprint, and bin-packing the same number of story points from the backlog into the next sprint. If you don't think toxic managers and scrum masters are going to use that "commitment…

Using scrum to extract commitments on a sprint is also just waterfall by another name.

Re: "No, it's less effort than that"

#113

Post by orwin »

nmstoker wrote: post #69

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

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

Re: "No, it's less effort than that"

#114

Post by wkat4242 »

Aeolun wrote: post #73
nmstoker wrote: post #69

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

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.

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

Re: "No, it's less effort than that"

#115

Post by maccard »

pydry wrote: post #112
regularfry wrote: post #94

Earlier quoted context omitted.

If you're doing Scrum, then you might have noticed that the Scrum Guide considers the contents of a sprint to be a "commitment" on the part of the team. That "commitment" is usually built by taking the number of story points delivered last sprint, and bin-packing the same number of story points from the backlog into the next sprint. If you don't think toxic managers and scrum masters are going to use that "commitment…

Using scrum to extract commitments on a sprint is also just waterfall by another name.

Waterfall is not the same as having a plan and commiting to delivering part of it

Re: "No, it's less effort than that"

#116

Post by mmcnl »

Aeolun wrote: post #79
throwaway091ba wrote: post #51

Whenever this estimation question comes up, developers rarely put themselves in the shoes of the business side, and try to understand why there needs to be an estimate, and why shorter is always better than longer. What they do instead, is try to protect their holy land of software development, and exacerbate the differences between engineers and "the others" - sarcasm and cynisism usually shine through at this time,…

What a weird thing to say. If you ask me how long it takes to grow a baby, and I say, 9 months. Am I not cooperating with the business when you want it in 6? No amount of effort on either your or my part is going to make the baby appear faster.

That's a bad analogy. Managing expectations is very rarely absolute or binary thing.

Re: "No, it's less effort than that"

#117

Post by jeltz »

danaris wrote: post #74
tyingq wrote: post #68

Dev teams have choices though. They can choose to use existing 3rd party code, services, etc, to accelerate development or not. They can choose some amount of non-functional requirements. They can choose the amount of "future proofing", abstraction, etc. And on and on...many choices that would drive timelines, trade speed for quality, longevity, maintainability, or cost, and so on.

But unless that 3rd party code, and those services, have already been discovered, evaluated, and learned by that particular dev team , integrating them might take more time than building something from scratch that meets the specific requirements at hand. And if it's built in-house, that means that in addition to being much more tailored to the organization's needs, it can be much more easily changed as those needs e…

Quite often using third party tools take longer time but still are worth it in the long term due yo lower maintaisnce and generally simpler tech stack.

Re: "No, it's less effort than that"

#118

Post by maccard »

regularfry wrote: post #94
pydry wrote: post #83

Earlier quoted context omitted.

>Relative sizing is still an estimate. Not one which would attract any pressure.

If you're doing Scrum, then you might have noticed that the Scrum Guide considers the contents of a sprint to be a "commitment" on the part of the team. That "commitment" is usually built by taking the number of story points delivered last sprint, and bin-packing the same number of story points from the backlog into the next sprint. If you don't think toxic managers and scrum masters are going to use that "commitment…

> If you don't think toxic managers and scrum masters

If your managers and PM's are toxic you've already lost and no process is going to fix it. The only move is to change your team in that case. If everywhere you look you only see toxic managers though, maybe you're the problem.

Re: "No, it's less effort than that"

#119

Post by jongjong »

smolder wrote: post #89
jongjong wrote: post #25

Unlike the meteorologist, the developer has the ability to bend reality a bit when it comes to estimates, but they can never bend reality in a way which makes it worthwhile. Cutting corners is almost always a mistake. It's a very short term move which may only make sense if the business is collapsing and looking for a quick exit.

You could spend 15 years cutting every corner imaginable as a self-professed genius 1-man engineering team until everything becomes unsustainable, feature work is impossible due to frequent fires, the business is faltering, and you can't even understand your own code any longer. Then, quit as soon as a new hire comes in so you can't be held accountable for your quagmire by other engineers. I don't really understand w…

Damn 15 years is a long time. I think the oldest ball of unmaintainable spaghetti code I saw was 3 years old and it was almost impossible to add or change anything. None of the developers who worked on it and had the most knowledge of it could explain how it worked, not even at a high level. Like they barely understood it better than non-tech end users.

Re: "No, it's less effort than that"

#120

Post by wkat4242 »

jeltz wrote: post #100
sokoloff wrote: post #78

Earlier quoted context omitted.

Unless you’re in the business of “selling hours”, why wouldn’t having something valuable done more quickly (and thus at a lower expense) be better, all else being equal? Sure, if you’re a contract dev shop who is marking up hours, then longer is better.

From my experience this is simply not true because all else is never equal. Employee burnout, technical debt, risks taken due to rushing, people not doing the right tradeoffs, etc.

Nobody cares about doing things right anymore. They just want quick wins. Meanwhile all the tech debt piles up.
Post reply on HN