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

231–240 of 388 posts

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

#231

Post by replyifuagree »

paulcole wrote: post #223
happytoexplain wrote: post #221

Earlier quoted context omitted.

This is a bitter exaggeration. Programming is indeed distinctly unlike almost all other work that we have built experience managing as a society. It might be more accurate to say that it combines properties from other existing types of work that are not seen combined in any other type of work.

Go to any thread here on HN about WFH, open offices, 8-hour work days, etc. and tell me I’m wrong.

Regarding open offices. The Fed commissioned MIT to do a study on the effect of public observation and found that it significantly reduced people's effectiveness at solving puzzles.

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

#232

Post by gnulinux »

dubcanada wrote: post #67
dlahoda wrote: post #55

Earlier quoted context omitted.

why shorter is always better than longer?

The OP is talking about business, so having something done in 2 days versus 4 days is always better. Ignoring everything else, less time is less money.

> Ignoring everything else

This is the problem with these kind of discussions. You cannot ignore everything else because everything else depends on 2 versus 4 days as well. Something that's done in 2 days can be exponentially worse than something done in 4 days such that in 6 months you can look back and rationally determine it was better to do it in 4 days.

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

#233

Post by replyifuagree »

bgribble wrote: post #91
masklinn wrote: post #72

Earlier quoted context omitted.

> The only magic wand in software development is to simplify requirements. The requirements are always wrong: too broad, too vague, based on invalid assumptions I think it's less simplification and more precision and completeness. Obviously if you have simpler requirements they more complete and precise, but the requirement might not actually be simplifiable. In which case what you want is better specification. "They…

As a developer I hate "precise" and "complete" requirements. Usually these extremely detailed roadmaps are just fairy tales. They indicate a management and product mindset that thinks you can pre-chew a developer's food for them and make things more predictable. In fact, what you are doing is tying the developer's hands and making it less possible for them to nimbly work around unforeseen obstacles or repurpose exist…

Yep it is very unlikely that the business silo has a clue what needs to be built.

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

#234

Post by ResearchCode »

maccard wrote: post #160
ResearchCode wrote: post #132

Earlier quoted context omitted.

The non-technical managers and agile coaches are the problem. That's why the best software projects don't have them. Linux kernel developers don't run story ticket velocity poker sprints.

An obsession with technical knowledge being superior to everything else is one of the most grating things about this community. > The non-technical managers and agile coaches are the problem. No, shitty managers are. In fact, most of the utterly useless managers and leaders I've had have been technical who just assumed that management, soft skills and leadership are "easy". > That's why the best software projects don…

Technical knowledge should be a necessary but not sufficient condition to become an engineering manager. A layman can't take a two day course with no exam and become a managing partner at a law firm. Why is that sufficient to become a micromanager in an enterprise software project?

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

#235

Post by mmcnl »

CipherThrowaway wrote: post #182
mmcnl wrote: post #110

Earlier quoted context omitted.

Honestly, I think you are an unwilling prime example of a disconnected developer. Why don't you instead try to found common ground and work from there? Who says "business people" aren't capable of dealing with uncertainty? You are making a caricature of a very simple, reasonable request. We're all just people with the same goals. Stop trying to enlarge differences.

>Who says "business people" aren't capable of dealing with uncertainty? Not defending the parent comment because it's way off base. But come on. You've never seen non-development stakeholders struggle to accept devs communicating uncertainty?

It totally depends on how you communicate the uncertainty.

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

#236

Post by NegativeK »

VonGallifrey wrote: post #171
dbalatero wrote: post #122

I think the biggest challenge I have is that people will immediately ask for estimates when the project is barely a paragraph description. On top of that, my feeling is always "it depends on how much tech debt is in the code after I look in there." The only reasonable response I've had is "I need 1-2 days to both push you on solidifying these requirements, and stop & audit the codebase to look for any risks before st…

This is the problem I have at the moment as well: Company Leadership asks for estimate with barely any information, I will then say that I need to learn more about the project and look into the codebase, leadership then says that they "just" need to have an estimate to approve this work and if they want to do this project at all. Around and around it goes until I give them a large estimate (which is large because of…

I was interviewing a CISO for a prior job. We asked how they would expand our team, given what we have and what we do. The candidate said that a typical team needs X, Y, and Z, but they really couldn't make an informed decision like that without being in the environment for at least a few months and seeing the way that things actually work.

My peers and I, who would report directly to the CISO, loved the answer. One of the CISO's potential peers on the interview panel thought that the candidate bombed the question, because "shouldn't they just know what's needed?"

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

#237

Post by NegativeK »

ResearchCode wrote: post #168
andyjohnson0 wrote: post #161

Earlier quoted context omitted.

> There is no evidence that you get better economic outcomes from micromanaging software engineers, and not for the lack of trying. Thats not really the point that my reply was addressing. Software production almost always takes place within a wider context of economic activity: product launch activities need to be scheduled, server capacity needs to be provisioned, hardware needs to be produced and assembled, people…

That's yearly planning. If estimation means giving your best effort to complete a project over the next year then that's not a problem. When you start micromanaging on a biweekly basis with daily status updates then it becomes a real problem.

I'm sorry, I can't imagine any business anywhere that would allow all software project estimates to have a precision of "about a year".

We might prefer that our projects be given unlimited leeway, but we still have to fit within businesses and their ability to forecast what they can sell, when the next round of bugs will be patched, and even how many developers should be hired.

Estimated is hard, leadership often fails to understand how hard it is, and it should always be accepted with a bunch of caveats, but it _is_ a very useful tool.

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

#238

Post by nine_zeros »

jalapenos wrote: post #159

It's more Machiavellian than that. What the middleman wants is a heads I win, tails you lose deal. He wants to present a low number, to encourage whoever he's dealing with on his end to do what he wants, gaining the benefit from that. So he'll use every technique under the sun to encourage devs to give him a number he likes more, while never making it look like an order or coercion (which would make it his number - s…

This is very true. And this is exactly my manager and the skip - pushing arbitrary deadlines, not because some customer is waiting for it, but because they want to look good to their own bosses. When the estimate inevitably fails, they all raise their hands and start pipping people for their own poor estimation.

As an engineer, imagine living under this constant stress, missing time with your family and friends, and for what? Just to make your own manager's incompetent estimation look good?

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

#239

Post by ResearchCode »

NegativeK wrote: post #237
ResearchCode wrote: post #168

Earlier quoted context omitted.

That's yearly planning. If estimation means giving your best effort to complete a project over the next year then that's not a problem. When you start micromanaging on a biweekly basis with daily status updates then it becomes a real problem.

I'm sorry, I can't imagine any business anywhere that would allow all software project estimates to have a precision of "about a year". We might prefer that our projects be given unlimited leeway, but we still have to fit within businesses and their ability to forecast what they can sell, when the next round of bugs will be patched, and even how many developers should be hired. Estimated is hard, leadership often fai…

How long does it take to fix a Linux kernel bug? Anywhere from a day to 20 years to never. It's either done as soon as possible, or it's done when it's done and that works for the best software projects.

Estimating is not hard, it's snake oil. That's how you end up paying $100M for burndown charts and a government website that doesn't work.

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

#240

Post by kjkjadksj »

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

Its also a little perverse how the solution is never “hey this estimate is too long, lets hire more staff so we can do the job well and finish on time.” Its always about squeezing more blood from the stone, burning out your employees and increasing your turnover rate.
Post reply on HN