Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

“Collaboration” is bullshit

joanwestenberg.com

Post reply on HN
Print view View original

171–180 of 193 posts

Re: “Collaboration” is bullshit

#171

Post by codebje »

parasubvert wrote: post #108
commandlinefan wrote: post #95

What I see - and have seen since I started doing this 30+ years ago - is that the date is _always_ more important than the actual deliverable. Always. Meeting "the date" is the only thing that's tracked (but it also never happens). It's even justified through vague analogies like Joel Spolsky's admonition that "you wouldn't buy a pair of jeans without knowing how much they cost" without ever doing a slightly deeper d…

IMO (also 30 years in the biz), it's rarely the date, that's #2. it's the budget. They'll forgive you if you're slightly late, they'll hate you forever if you ask for more money. Agile works really well if you have a good product owner that has secured appropriate budget for the level of uncertainty in the endeavor & can make decisions and not be overridden by extrinsic forces. Everything else is negotiable.

As far as software development goes, money is almost perfectly correlated with time.

Re: “Collaboration” is bullshit

#173

Post by rstuart4133 »

cmenge wrote: post #137

Read a super interesting paper by McEntire lately, “The Organizational Physics of Multi-Agent AI”. In short, he proved that even AI agents exhibit all the dysfunctions one would normally attribute to human shortcomings / politics / laziness etc. Either way, I think the point is strong: if the organization is bad, you end up doing mostly work about work which is exhausting. Small, effective teams with super high accou…

Your take is far better than the OP. I didn't figure out what point the OP was trying to make.

Re: “Collaboration” is bullshit

#174

Post by the_real_cher »

t43562 wrote: post #126
the_real_cher wrote: post #78

Earlier quoted context omitted.

If ownership is clearly defined the person who screwed up should be clear.

You can own something but still be blocked by other people who should in theory enable you but have other priorities. Another example: bugs that are not found by testers - whose fault is that - development or test? Clarity is just another way in which one person or group try to lay blame.

It's not a screw-up if you're blocked though.

Those are two different things.

I understand your point.

Guess it boils down to, a toxic environment can make any system not work.

Re: “Collaboration” is bullshit

#175

Post by mizzao »

If this article is true, then a single talented person with a good workflow* for operationalizing a bunch of AI agents/pipelines should be able to get a lot of things done. Way more than before.

* I believe these workflows aren't entirely invented yet; it currently seems to be mostly token-burning with the illusion of productivity, measuring inputs rather than outputs.

Re: “Collaboration” is bullshit

#176

Post by atoav »

parasubvert wrote: post #108
commandlinefan wrote: post #95

What I see - and have seen since I started doing this 30+ years ago - is that the date is _always_ more important than the actual deliverable. Always. Meeting "the date" is the only thing that's tracked (but it also never happens). It's even justified through vague analogies like Joel Spolsky's admonition that "you wouldn't buy a pair of jeans without knowing how much they cost" without ever doing a slightly deeper d…

IMO (also 30 years in the biz), it's rarely the date, that's #2. it's the budget. They'll forgive you if you're slightly late, they'll hate you forever if you ask for more money. Agile works really well if you have a good product owner that has secured appropriate budget for the level of uncertainty in the endeavor & can make decisions and not be overridden by extrinsic forces. Everything else is negotiable.

I program for 20 years now and I think that what many people do wrong about these estimates is that they give them too early. The truth is that for many project the only truthful answer you could give someone on the question hoe long it takes is: "That depends on many things some of which I don't know, some of which we both don't know and some of which potentially nobody knows." After that you should say: "In my experience it takes betwern x and y weeks, with a lot also depending on how responsive your side is."

Time estimates are always hard, not only in programming. And outside of programming one of the main insecurities is customers changing the plan or wanting adjustments. This is the side you can't really control, so it is best to get a feeling for the customer, their communication patterns and their expectations early on and factor it in. The other insecurity is tough problems you encounter during the programming phase. How well you can deal with those depends a lot on how experienced your programmers are and how much they were involved in the inital process.

The truth is that the latter insecurities make up a main part of the whole thing and it has to be okay to tell a customer you can't give them an estimate before you know some more details.

Re: “Collaboration” is bullshit

#177

Post by parasubvert »

codebje wrote: post #171
parasubvert wrote: post #108

Earlier quoted context omitted.

IMO (also 30 years in the biz), it's rarely the date, that's #2. it's the budget. They'll forgive you if you're slightly late, they'll hate you forever if you ask for more money. Agile works really well if you have a good product owner that has secured appropriate budget for the level of uncertainty in the endeavor & can make decisions and not be overridden by extrinsic forces. Everything else is negotiable.

As far as software development goes, money is almost perfectly correlated with time.

That's never been true. At minimum, as it's missing the most important variable: quantity of people. 1 person working for a year vs. 12 people working for a month could cost the same and have dramatically different results. And it ignores so many other aspects of effective use of productive capital in software dev (toolchains, cloud, AI, etc.)

Re: “Collaboration” is bullshit

#178

Post by lelanthran »

> The pattern recurs because it describes something real about how effort is distributed inside groups, where a fraction of the people do most of the work, and the rest provide what you might ~charitably call “structural support.”

And LLMs is about to make sure that the structural support people are 99% of the team and the people who do most of the work are 1%, orchestrating a team of agents...

Re: “Collaboration” is bullshit

#179

Post by sunrunner »

parasubvert wrote: post #161
sunrunner wrote: post #122

Earlier quoted context omitted.

Is that three kinds of regular meetings? Because I count 8 meetings (and four kinds, as I don't think I've ever had demo and retro combined due to different groups of people being in both).

Sure, I was being loose with my terminology, you are right to correct this. the point was in a 40 hour work week, it's reasonable for 15% of it to spent in coordination meetings, while 85% is directly related to progress. Usually the retro is after the demo when other folks leave the room / drop from the zoom :-)

Not correcting, just clarifying for myself. I sure wish I had such a controlled environment with only 15% of time in coordination and where standup actually was 15 mins and not a segue into the everything meeting.

Re: “Collaboration” is bullshit

#180

Post by bambax »

xorcist wrote: post #53
bambax wrote: post #46

This article is so true. "Collaboration" is how nothing ever gets done; we have this expression: "designed by committee"; we should also have "made by collaboration". What's depressing is that it's like Fred Books' book never happened: most managers think the way to solve IT problems is just to trow more people / more money at it until it gets solved; and they're all surprised when it doesn't work, but try again the…

Right. But more often than not, the problem that's being solved is "we have gotten money to throw at things", so the answer of throwing in many more people to busywork kind of makes sense. That's before we even think about all the consultants and similar roles where busywork really is work. Then all the organizational or agile roles. The fact that some product gets shipped and we still have customers is good, because…

> But more often than not, the problem that's being solved is "we have gotten money to throw at things"

Yes, that's a great observation. Not easy to fix though.

Post reply on HN