Live data from Hacker News

"No, it's less effort than that"

smartguess.is

101–110 of 388 posts

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

#101
post #79

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.

What if you push really hard though

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

#102
post #46

If developers did not approach projects with the goal of adding acronyms to their resumes and infuse every project with the latest cargo cult du jour it would improve the ability to predict timelines. Pick boring technology, that the team is already comfortable with, when possible. Keep the teams as similar as possible, Keep running projects the same way, when possible I am not saying it will get things perfect, but…

Developers do not choose the tools. Not in agile/scrum companies. Heck, they are not even allowed to choose the variable names by themselves.

What? That seems like it would vary from company to company. My company does scrum and developers choose which technologies to use, which seems like it's probably common...

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

#103
Estimates are just that - estimates.

More importantly they’re estimates of effort - not of time. If you estimate in time you’re tracking time over time and as such not your ability to estimate time.

Estimating within the team should be for the team, not for the business (directly).

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

#104
post #71

Earlier quoted context omitted.

Please don't generalise or you wipe out the occasional good that does exist.

Now seriously, my comment is a call for people to acquire professional communication skills, because they are extremely useful when negotiating work in far too many areas to count. Such advice getting down voted indicates how little value quality communications has within the software developer community - to the industry's demise. Communications are everything, and if you don't have good communication skills you get…

Tbh, I downvoted you not because I don’t value quality communications, but because negotiating around your capacity is a small slice of professional communication, and your approach is needlessly adversarial. You will experience a lot of useless friction in your life by taking that approach.

Good communication isn’t adversarial: by the time it becomes adversarial, you’ve already lost. It can include solid documentation, taking the time to mentor others, respectful but clear code reviews, helping others argue your case for rescoping, presenting your work at meet-ups or conferences, hallway testing a new feature, listening to teammates explain an approach…

…and yes, sometimes negotiating capacity. If that feels like an adversarial conversation, then your manager sucks, and you should find a new one.

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

#105
post #79

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.

In that analogy, a far more common situation is the developer saying “I don’t know”, “depends on what kind of baby you want”, and “5 years and you’ll have a 1st grader”.

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

#106

The only magic wand in software development is to simplify requirements. The requirements are always wrong: too broad, too vague, based on invalid assumptions The real genius is to propose a simplified solution, by discarding some assumptions. This is the best and only way to shrink the schedule

And devs are in the perfect position to take on this responsibility. They usually have sufficient domain knowledge and know what it takes to build stuff in this context.

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

#107

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…

That's why developers should be the ones taking a step forward to make vague requirements "complete" and "precise". They will satisfy the business goals and there won't be fairy tales.

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

#108

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

I agree 100%. Too many software developers feel entitled and think they do all the hard work and everyone else should just try to understand their domain or get lost. This attitude will get you nowhere.

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

#109

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

FWIW, some version of your rant occurs in almost every industry. Even doctors have hospital administrators complaining about how arrogant and non-business minded they are, how they are opportunistically defending their turf and so on. What you're talking about is not specific to devs but a general symptom of politics and friction between the different layers of an organization.

Devs always lean more cynical than the rest of the org, but the "prima donna devs refusing to acknowledge the need to deliver" schema only emerges in poorly managed organizations and teams. There is always some push and pull, but usually it's within a healthy balance.

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

#110
post #63

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

Well then bussiness people are also disconnected from reality. If a developer can write code and estimate and deliver in time for bussiness, then he is not an employee. He is a founder. What you want is people that deliver like a founder but that don't get any share of the profits. You want gullible people.

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.
Post reply on HN