He spends the first half of his presentation debunking the meme that OO was created for working with teams, not that it happens to be good for working with teams. Your quoted bit is not evidence of someone making the first claim, only the second.

> You’ll get better results if you just search for

That isn't what @bevyenjoyer told me to do. Moving goal posts.

That's why it's important for the OP to provide a reference, so from the beginning we are all talking about the same thing.

This is not moving the goal posts. Different people making the same claim may use different phrasing, and Google very much has recency bias. By searching for something slightly different we deprioritize the video we’ve already seen.

A primary source: https://www.youtube.com/watch?v=_ahvzDzKdB0

The only place "team" shows up in the transcript is here:

> So. Language design is not at all the same kind of work it was thirty years ago, or twenty years ago. Back then, you could set out to design a whole language and then build it by your own self, or with a small team, because it was small and because what you would then do with it was small.

Which is not about OO at all. Got an actual quote or is this link really just an interesting but irrelevant non sequitur?

EDIT: For those coming in later who don't feel like clicking random Youtube links, parent post is referencing Steele's talk "Growing a Language".

You know that thing people do where they say the same thing using different words? You’ll have to comprehend the words rather than merely pattern matching on a specific phrase.

In particular, note how he talks about growing the language by adding new things to it which are like the existing parts of the language. Contrast that with APL, where the existing parts of the language all had funny symbols, but new things added by the user needed alphanumeric names. In Java the language gives you a bunch of classes and interfaces and whatnot, and you extend the language by defining your own classes and interfaces. You don’t have to do this yourself, of course, since you can include libraries alongside your code. Those libraries can extend the language by defining new classes and interfaces.

As he says:

    43:54 Back then, you could set out to design a whole language and then
          build it by your own self, or with a small team, because it was small
          and because what you
    44:02 would then do with it was small. Now programs are big messes
          with many needs.
    44:07 A small language won’t do the job. If you design a big language
          all at once and then try to build it all at once, it will
    44:15 fail. You will end up late and some other small language will
          take your place.

It's a remarkable stretch to go from those words to "OO was created for working with teams." It is neither implicit nor explicit in the talk and I don't know why anyone would make the claim you are making.

EDIT: You seem to be conflating the two ideas still. OO being created for teams is a different claim than it being good for teams. At most, you could stretch Steele's talk to the second, but not to the first.

True, he doesn't come right out and say the words. But don’t lose sight of the context. This is the big Keynote speech at a conference called OOPSLA, or “Object-Oriented Programming, Systems, Languages & Applications”, in 1998. It is safe to say that the audience has heard of Java by now. They already know that the core language design choice made during the creation of Java was to make it object—oriented. Objets are everything and everywhere in Java. Even the simplest “Hello World” program in Java has to be written as a class with a a Main method.

This talk tells us why he and the others at Sun made that choice. He says right there that he wants Java to enable people to write large programs. He specifically contrasts it with the small languages and small programs of the past, the kind that were invariably written by individuals or small teams.

This is what he believes OOP is good for, and why researchers have been studying it for so long. He is reinforcing the belief of the attendees that OOP in general, and languages like Java specifically, are a panacea created for the explicit purpose of letting engineers work more efficiently together on large, complex systems.

We know from the historical record that early researchers did not have this belief. We know that many practitioners of the 90s and 2000s did. This talk may not be the genesis of that belief, but it is proximate to it.

The fault for this myth will almost certainly be marketing. The best place to look probably won't be something for those in the trenches, but more targeted at management types.

I've listen'd to just past:

24:50 -- "A lot of people talk about these things. They talk about those compile time hierarchies and all that sort-of stuff; and they say - like you know, here's the thing that you just don't understand, it's all about large teams …"

Is there some example that you can point me towards, where a lot of people are saying compile time hierarchies are all about large teams?

(I suppose Ada is an example of design for programming-in-the-large.)

Is that a source given during "The Big Oops: Anatomy of a Thirty-Five-Year Mistake"? Otherwise the author might reasonably say that isn't what they meant.

A lot of people have said a lot of things about OOP for decades. So looking at the context in which something was said is an ordinary sanity check.

It is not moving the goal posts.

It is moving goal posts.