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

141–150 of 388 posts

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

#141

Post by throwaway98797 »

GoToRO wrote: post #63
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,…

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.

i envy you that you managed to live your life with this kind of belief

that’s like a sales guy closing a deal…

you did one piece of the puzzle and dealt with one type of headache

you clearly have no clue what founders actually do

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

#142

Post by marginalia_nu »

paulsutter wrote: post #23

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

Yes. I very much agree. Not only are most software bugs actually requirements bugs, the speed you can build software with good requirements is absolutely bonkers.

I've seen a project go from an empty repo to production in two months with a set of requirements that were completely unambiguous and rock solid. I've also seen ambiguous and vacillating requirements drag out the implementation a ~30 LOC feature for months.

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

#143

Post by briHass »

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.

Large orgs almost become like a bloated government in that way: groups start to construct little fiefdoms with rules and policies that are ostensibly constructed to improve quality. However, those rules end up becoming bludgeoning tools used by nefarious actors in those groups.

The real problem is that nobody ever steps back and asks: are all these rules actually helping to improve quality of the software. Is the cost of the reduced velocity and overhead actually worth it in the end.

Then, the org does layoffs and all that policy is still in place without the necessary people to supported the bloated workflow.

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

#144

Post by ResearchCode »

gardenhedge wrote: post #139
ResearchCode wrote: post #133

Why are you pushing software engineers for "estimates"? You don't ask mathematicians how long that conjecture will take to prove. It's done when it's done.

Estimates help planning. The problem is that they often travel through a company and become immovable deadlines.

Planning too often is also a problem. You should not do it more often than every three to six months.

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

#145

Post by dahart »

bsenftner wrote: post #96
School-Cotton wrote: post #87

Earlier quoted context omitted.

Then you’re just empirically wrong. I’ve never had managers who didn’t want me to have professional communication skills in the ten years I’ve been in our industry.

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 deadlines or work, but to spend more time understanding requirements, and simply try to break down long-running projects into small pieces that can be estimated more accurately. One of the biggest problems I’ve witnessed in software is that estimates in units of years are always very wrong, while estimates in units of days or weeks are pretty good.

I have to agree with the parent; you’re making incorrect assumptions and maybe projecting your own bad experience, and ending up accidentally saying something that isn’t true.

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

#146

Post by dtgriscom »

My manager once gave me a succinct method for accurately estimating project times:

1. List all the necessary tasks

2. Estimate the time for each task

3. Add up all the times

4. Multiply by π

If using unknown technology, that last step should be "multiple by π^2".

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

#147

Post by rrr_oh_man »

regularfry wrote: post #81
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 think there's an important detail you might have left out of your 30 minute example: are you asking for how long the effort on the specific task will take, or what the time gap will be between right now and the moment it's delivered? Because in almost all teams both are dominated by the task waiting for something, but in the latter case it's especially true. Actual hands-on-keyboard time is usually a rounding error…

> Unless a team has put hard work into unintuitive ways of working, the average ticket will spend grossly more time waiting than actually being worked on.

What do you mean by "unintuitive ways of working"?

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

#148

Post by paulryanrogers »

coldtea wrote: post #128
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…

> Is there anything I could be doing better here? Yes. Not give a fuck about the code debt and quality, and just rush out something that barely works. That will keep them satisfied.

Having built a few of these and inherited a few, please don't. They become brittle and future changes become increasingly difficult, until velocity grinds to a halt. Then you're just firefighting constantly.

My guess is there is a happy medium between never changing and staying on the cutting edge. A place where you can ride the current of tech, FOSS, dev communities and talent pools.

If course what this looks like day to day and in pointing poker will vary. Ideally there is a seasoned architect on every team who can steer the biggest decisions away from the hazards.

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

#149

Post by rrr_oh_man »

briHass wrote: post #143
Aeolun wrote: post #73

Earlier quoted context omitted.

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.

Large orgs almost become like a bloated government in that way: groups start to construct little fiefdoms with rules and policies that are ostensibly constructed to improve quality. However, those rules end up becoming bludgeoning tools used by nefarious actors in those groups. The real problem is that nobody ever steps back and asks: are all these rules actually helping to improve quality of the software. Is the cos…

> are all these rules actually helping to improve quality of the software

While I agree with your sentiment, high quality software (and: what is high quality, anyway?) is not necessary the goal of an enterprise.

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

#150

Post by [deleted] »

throwaway98797 wrote: post #141
GoToRO wrote: post #63

Earlier quoted context omitted.

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.

i envy you that you managed to live your life with this kind of belief that’s like a sales guy closing a deal… you did one piece of the puzzle and dealt with one type of headache you clearly have no clue what founders actually do

[deleted]
Post reply on HN