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

331–340 of 388 posts

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

#331

Post by tacocataco »

xorcist wrote: post #154
bgribble wrote: post #91

Earlier quoted context omitted.

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…

Well, that's the nature of software. If the requirements were actually precise and concrete , you could commit them to git and that would be the end of it. The fact that they aren't is a sign of information deficit and this must be understood by all parties if we should have any chance of a productive outcome.

What if one party is incentivized to create said information deficit?

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

#332

Post by rukuu001 »

corry wrote: post #167

“Pushing sales people to increase their amount of sales/quota is like asking meteorologists for sunshine”. Hmmm it doesn’t seem unreasonable in that context? You’re really asking people to work more effectively, to accomplish the same amount of work more quickly. It’s like asking sales people what their quota should be. They pick a number that is no-brainer hittable, because there is a lot of complexity and many unkn…

Yeah I think of sales people like farmers - there’s a lot they have to get right to get a good crop, but if conditions are poor, nobody gets anything.

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

#333

Post by paulcole »

replyifuagree wrote: post #327
paulcole wrote: post #266

Earlier quoted context omitted.

Just proving my point. Significantly reducing some tech bros ability to do puzzles doesn’t mean that private offices are needed to make the 10,000,000th Rails app.

That entirely depends on whether or not the team is making something that is going to fulfill an unmet market need. If they are in the majority of developers being mismanaged to crank out software that nobody wants, then have them code in an open office space with bullhorn wielding circa 1890s speed bosses yelling at them to type faster. It really makes no difference as most legacy business teams shirk their responsi…

Yes, that’s exactly my point.

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

#334

Post by replyifuagree »

pixl97 wrote: post #322
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.

Yep, this sounds like the kind of project you make a guess, write up, and it works in that amount of time on your machine. Then you push it out into the field and you get flooded with calls on it not working. Turns out it only works in your version of Excel on Windows without some particular set of patches installed. Manhattan Project was easy, they didn't have to worry about any backwards/multi-platform compatibilit…

lol, I'm just thinking of how awful the Manhattan project would have turned out if it had half the invisible things that can go wrong in software deployments.

If software caused mushroom clouds each time it had a problem in the field, nobody would let MBAs run software projects!

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

#335

Post by gen220 »

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…

You’re doing the right thing, but you need to speak their language.

In Agile speak, that’s a 3 point spike ticket, for which the deliverable is a detailed set of requirements and deliverables with estimates with considered trade-offs. It’s a totally normal thing to do.

You can give an estimate before doing the spike, but maximally caveat it. Like “60% confidence it’ll take fewer than 3 weeks, 80% 5 weeks, 90% 6”.

I’d generally recommend refusing to give deadline estimates beyond a week or two (unless it’s absolutely necessary as it sometimes is), preferring piecemeal estimates (i.e. this project is composed of 7 deliverables each taking 1-2 days of work). Reason is that it might take 10 days of engineering work to do something, but due to shifting priorities etc., the calculus of computing a deadline is basically pointless.

If the “managers” don’t understand any of this, it’s never going to be peaceful unfortunately.

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

#336

Post by mardifoufs »

dasil003 wrote: post #261

This article is extremely weak, pandering to engineers beset by clueless pointy-hair antics, without acknowledging that engineers can suffer from their own blind spots, regardless of whether stakeholders have the technical background to understand it or not. The elephant in the room is this: a team can not produce good work without both competence and trust in equal measure. An immature engineer may assume a business…

Oh my god thank you. Software engineering seems to be the only field where it seems like these types of super weird arguments about being too special or unique to follow or apply any business process are common, coupled with a vibe of "we are way smarter than everyone else".

Why are these people surprised that other stakeholders won't just accept a "trust me bro, it's ready when it's ready you just have to go with it" when nothing else works like that in the business world.

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

#337

Post by zeroCalories »

em-bee wrote: post #307
zeroCalories wrote: post #255

Earlier quoted context omitted.

My argument is not assigning blame, but explaining why the article will not convince many managers. It works assuming either side can be greedy or fair.

many projects everywere are failing their estimates. so the idea that developers overestimate the time it takes to complete a project is not supported by statistics. Management has to push for lower estimates because developers have an incentive to overestimate to make life easier. this statement as written clearly supports management and puts blame on developers. if that wasn't your intention then it could be expres…

> many projects everywere are failing their estimates. so the idea that developers overestimate the time it takes to complete a project is not supported by statistics.

Can you cite your own statistics? But even granting your assertion, it still would not matter because in the end the project will be done sooner the more pressure is put on, so it's better to underestimate and plan for delays than to over estimate. Managers often have two different deadlines for projects: the official deadline, and the real deadline. They simply don't tell their reports the real deadline. At many tech companies it's not unusual that a team will only make 70%-90% of their OKRs, and if they consistently make 100% they are said to be too conservative in their ambitions and encouraged to do more.

> this statement as written clearly supports management and puts blame on developers. if that wasn't your intention then it could be expressed more neutrally:

I believe my intention was clear from the other responses I got that understood what I was saying. But that's not just what management believes, I also believe that, so your version would not be a better expression of what I meant.

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

#338

Post by ResearchCode »

NegativeK wrote: post #316
ResearchCode wrote: post #239

Earlier quoted context omitted.

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.

You write the check once a year and plan projects no shorter than three months.

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

#339

Post by verve_rat »

alanfranz wrote: post #272
smokel wrote: post #270

I'm sometimes a bit ashamed of the IT sector as a whole. I have been programming professionally for more than 20 years, but I have not seen much improvement in time to delivery. For each step forward, we seem to be taking two steps back. I can't blame the developers, but I wonder who to blame instead. The first suspect is: the internet. It may seem like a great invention, but having machines connected at all times, w…

> but I have not seen much improvement in time to delivery. Is this true, by the way, or it’s just our hedonistic treadmill? Nowadays it’s extra fast to deliver and serve a lot of functionalities worldwide. Thing that would require a dev team are handled by a free saas out of the box. But our implied non-functional requirements have grown exponentially. Twenty years ago, if a business critical software was offline fo…

And the expectation that every business should act like they are facebook.

No, if your system goes off line for 20 hours a year barely anyone will notice, it will have way, way less impact to your business than spending the money to make sure that doesn't happen.

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

#340

Post by rrr_oh_man »

CipherThrowaway wrote: post #219
rrr_oh_man wrote: post #189

Earlier quoted context omitted.

It might be, if it’s directionless pushback instead of genuine curiosity to understand the need of the internal customer. From my personal experience, people are often positively delighted when you make an effort to try to understand them and their needs. Not shooting down your experience, but from my perspective it could be seen as a straw man argument in favour of never trying in the first place.

I'm not saying "don't try." And I'm also not disagreeing that people, on the whole, respond well to attempts to understand them and communicate with them. My observation is that it is ultimately organizational culture that frames the way people communicate and how they understand each other. Individuals can move the needle a bit depending on the size of the company and their position in it. But largely they are power…

Thanks for the clarification!
Post reply on HN