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

311–320 of 388 posts

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

#311

Post by verve_rat »

jghn wrote: post #244
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…

Sometimes, but not always. I've been on both sides of this situation. As an engineer I'm always adamant - yep, no way this could be done any faster and please stop pressuring me to just get the number you want to hear. It'll be done when it's done, and it'll be robust and good. Now please go away and let me cook. But when I've been the manager pushing for smaller estimates, it's been because the business realities we…

What you are describing is shit managers.

If corners need to be cut for valid business reasons then there shouldn't be any real push back from the devs, because they have the business context laid out for them.

Every dev I've ever worked with will say "yup, I understand. I might not like it, but I understand" when given the context of pushes for quicker delivery.

But that requires understanding on both side that you are sacrificing quality to hit a date, and that has its own costs.

Mostly this all boils down to: talk to people like they are you colleagues, don't order them around, find a solution together.

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

#312

Post by replyifuagree »

paulcole wrote: post #267
replyifuagree wrote: post #227

Earlier quoted context omitted.

One thing to watch out for is confusing IT work for dev work. I see this a lot with business folks. An example of IT work is installing MS Office on a laptop by hand. An example of dev work is integrating VBA into excel so that office users can automate excel using VBA.

But yeah thats kinda my point. Integrating VBA into excel isn’t the Manhattan Project. Unless it’s your first job you can probably break the project down into steps and give a decent estimate of time on each.

Integrating VBA into excel was an interesting one as the excel team refused to just pull it in as a dynamic dependency but wanted it embedded straight into the deployment to avoid the DLL hell that was common on the windows platform. In addition going from having no automation via something like VBA to having automation required some pretty complex work.

As for the Manhattan Project, you might want to think on the difference between the words complexity and difficulty. And then you might consider that when working with nuclear material to create the world's first nuclear bomb, you would want to keep the complexity as low as possible, sheerly out of self preservation.

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

#313

Post by verve_rat »

dahart wrote: post #145
bsenftner wrote: post #96

Earlier quoted context omitted.

You manager wants you to agree to the work they ask you to perform, and they want to load you up with work to maximize your efficiency. How one negotiates when you're reaching capacity is professional communications. If one is unable to attain work/life balance that is due to a lack of communication skills, the lack of the ability to explain you're past ordinary capacity, burning your health. Our industry is over run…

My current manager asks me to define the work, and has asked me not to do certain things because he feared it would overload me. He values professional communication and endorses people who want to improve them, going so far as to allocate work time and support them financially in their efforts to learn. I’ve also been a manager at 3 different companies, one of them my own, and my philosophy has not been to push dead…

They're not wrong. Our industry has a burnout problem. Some places are nicer than others to work at, but that doesn't mean the industry as a whole doesn't have problems.

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

#314

Post by pfsalter »

theptip wrote: post #279

I dislike the framing here, it disempowers the team and sets up a hostile lens towards stakeholders. As the product team, you are in general optimizing between quality, scope, and timeline. Pick values for two, the other one will be determined. So if a stakeholder communicates a timeline constraint, you can work with them to achieve it by cutting quality or scope. For example if the urgency is that they need to give…

Completely agree, the article reads more like someone who thinks they are doing research rather than development. There's no esoteric perfect form for software that needs to be discovered, there's a set of patterns and structures that can be learned before the project starts.

Analogies are often unhelpful because people argue about the analogies instead of the actual problem at hand. If you can't communicate why these things are hard, and why 'do it faster' won't always get results, you need to get better at dev management.

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

#315

Post by paulcole »

replyifuagree wrote: post #312
paulcole wrote: post #267

Earlier quoted context omitted.

But yeah thats kinda my point. Integrating VBA into excel isn’t the Manhattan Project. Unless it’s your first job you can probably break the project down into steps and give a decent estimate of time on each.

Integrating VBA into excel was an interesting one as the excel team refused to just pull it in as a dynamic dependency but wanted it embedded straight into the deployment to avoid the DLL hell that was common on the windows platform. In addition going from having no automation via something like VBA to having automation required some pretty complex work. As for the Manhattan Project, you might want to think on the di…

Neat!

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

#316

Post by NegativeK »

ResearchCode wrote: post #239
NegativeK wrote: post #237

Earlier quoted context omitted.

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.

So all custom software should be written with a blank check and an unlimited timeframe?

You're either arguing for something that can not work in commerce or you're not arguing in good faith; I'm not sure which.

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

#317

Post by [deleted] »

bgribble wrote: post #99
fasteo wrote: post #21

1975: Fred Brook's wrote[1]: “The bearing of a child takes nine months, no matter how many women are assigned.” Can't get better than this [1] https://en.wikipedia.org/wiki/The_Mythical_Man-Month

I have even smart managers look me in the eye and say things like "can we parallelize parts of this? let's map out the dependencies." EVERY EXTRA PERSON YOU ADD MAKES IT TAKE LONGER. The fastest delivery is a solo developer that you get out of their f**ing way and let them work.

[deleted]

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

#318

Post by [deleted] »

sokoloff wrote: post #86
nabla9 wrote: post #17

My estimate math: R = t × [1.1^ln(n+p) + 1.3^X] R - time it really takes. t - shortest possible time it would take without need to communicate. n - number of people working and involved during the process, both customers and developing organization. p - longest communication distance network involved in the project (typically from the lowest level developer to the end user) X - number of new tools, libraries, techniq…

Why does zero new tools (X) add time? Alternatively, why does one new tool add so little time?

[deleted]

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

#319

Post by wkat4242 »

latency-guy2 wrote: post #286
wkat4242 wrote: post #120

Earlier quoted context omitted.

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

Seeing as there's tech debt from 40 years ago people like me are still paying, seems like devs don't know how to do things right at all.

Well yes and no.

That tech debt from 40 years ago was usually perfectly adequate back then. It's only tech debt now because it's become unmanageable due to changing environments, programming languages, APIs, security concerns etc.

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

#320

Post by Aeolun »

mmcnl wrote: post #116
Aeolun wrote: post #79

Earlier quoted context omitted.

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.

If you can start asking questions like “do we actually need a baby”, “what are the specifications for hair color and nose length”, “does it need to be a human baby”, “how about we start at an embryo instead” etc. the whole equation changes. But most people asking for the estimate aren’t actually interested in providing any of that information.

They want to give you a vaguely defined blob of half finished specifications, and expect a perfectly accurate assessment of the time it will take, and also to be able to change the vaguely defined blob as they go along without effect on the given estimate.

Post reply on HN