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

321–330 of 388 posts

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

#321

Post by Aeolun »

rrr_oh_man wrote: post #149
briHass wrote: post #143

Earlier quoted context omitted.

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.

Faster development almost invariably is though. Everyone wants to be able to say their project got done on-time and according to spec.

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

#322

Post by pixl97 »

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.

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 compatibility.

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

#323

Post by replyifuagree »

paulddraper wrote: post #257
xctr94 wrote: post #253

Earlier quoted context omitted.

This is ridiculous. The number of LOC doesn’t define whether something is well implemented. You can’t crank out a better design or proper feature implementation by asking developers to write code faster or write more code in a given day.

> The number of LOC doesn’t define whether something is well implemented. And a phone call doesn't mean a sale closes. See conversation upthread.

But 100 phone calls will, there is actually no such relationship in code - in fact deleting code significantly reduces liability, I guarantee reducing sales calls will not have the same effect.

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

#324

Post by pixl97 »

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…

Even this isn't really looking at the problem correctly.

If your two man organization if one person steals the source code or slips in some back door into the code, it should be somewhat obvious who did it.

On the other hand in that large enterprise someone doing the same could lead to an international incident. And with that many people you are going to have nefarious actors at some point and you need to think about how to minimize their damage.

It's likely you're falling into the same trap of understanding why Chestertons fence was put up in the first place.

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

#325

Post by lmm »

23B1 wrote: post #201
lmm wrote: post #80

Earlier quoted context omitted.

> developers rarely put themselves in the shoes of the business side, and try to understand why there needs to be an estimate I put plenty of effort into trying to understand. 95% of the time there's no business reason. Most of the time someone just wants to put a number on their powerpoint for some organisational politics nonsense. Sometimes the business wants to decide whether to do thing A or thing B (in which cas…

> Most of the time someone just wants to put a number on their powerpoint for some organisational politics nonsense. Yes. Thats how coalition-building, budgeting, and reporting works in business. Not saying it should dominate your schedule, but it's just how organizations work. Engineers/Developers are part of the org – not some special snowflakes that are above or beyond politics.

> Thats how coalition-building, budgeting, and reporting works in business. Not saying it should dominate your schedule, but it's just how organizations work.

Nah. Internal competition is a negative for the business. Selfish individuals do it so that they can get better results for themselves. Refusing to take part is the right thing for the business.

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

#326

Post by paulcole »

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…

Exactly, I’m glad you’re on my side with this. It’s great to have your support.

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

#327

Post by replyifuagree »

paulcole wrote: post #266
replyifuagree wrote: post #231

Earlier quoted context omitted.

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.

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 responsibility to get out of the building and figure out the real needs anyway, so might as well let the devs work on their craft until a real opportunity to make a difference comes along.

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

#328

Post by replyifuagree »

roenxi wrote: post #95
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,…

Everyone understands that why the business needs to an estimate and that shorter is better than longer. There is no ambiguity there at all. The complaint is the phrasing like the developer can know when it'll be finished. Someone's ability to deliver value quickly is unrelated to their ability to estimate how long it will take. They can get their estimate completely wrong and deliver huge value. And we all know if th…

>if there was some way of estimating how long software tasks would take, software companies would hire a professional estimators

That's awesome. In my feistier days I would have used that at work!

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

#329

Post by briHass »

pixl97 wrote: post #324
briHass wrote: post #143

Earlier quoted context omitted.

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…

Even this isn't really looking at the problem correctly. If your two man organization if one person steals the source code or slips in some back door into the code, it should be somewhat obvious who did it. On the other hand in that large enterprise someone doing the same could lead to an international incident. And with that many people you are going to have nefarious actors at some point and you need to think about…

The problem is, the whole mess becomes so abstracted away from the real goal: shipping software to customers and making money. Government can get away with it, because they're the only game in town, but a company doesn't have the luxury of operating with a crippling level of inefficiency for long.

Whatever 'deal with the devil' that existed when the fence was erected may no longer be relevant or worth the overhead, but the policies live on. There may even now be individuals who's jobs are now directly related to enforcing/implementing the policy, and they have an interest in perpetuating it at any cost.

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

#330

Post by tasuki »

I don't get the meteorologist analogy: The meteorologist does not create the weather. The software development team does create the software.

Also weather is (somewhat) possible to predict. In software, the unknown unknowns are a problem, so all estimates are basically bullshit.

Post reply on HN