> … didn't scale to multiple users trying to share code…

Just curious, what process did you tell them to get past their "scattergun approach"?

I never looked at the 1984 "Smalltalk-80 The Interactive Programming Environment" book until about a year ago, so very much with the benefit of hindsight —

"At the outset of a project involving two or more programmers: Do assign a member of the team to be the version manager. … The responsibilities of the version manager consist of collecting and cataloging code files submitted by all members of the team, periodically building a new system image incorporating all submitted code files, and releasing the image for use by the team. The version manager stores the current release and all code files for that release in a central place, allowing team members read access, and disallowing write access for anyone except the version manager." (page 500)

http://rmod-files.lille.inria.fr/FreeBooks/TheInteractivePro...

Initially we followed that model, we would have a designated integrator that incorporated changes when you hit a milestone, and ways of filing that into other developers images as they went, but it was very error prone and a lot of regressions would pop up for the integrator as they struggled to keep up.

Envy fixed that, you could start with a fresh envy image and grab your updates. You could also isolate developers in their own branch like git and get proper warnings when you had integration issues when merging.

Basically the integration job went from full time to a couple of hours a week.

Thanks. fwiw Seems to me that what you describe is different.

> … filing that into other developers images as they went…

Seems to me that after "building a new system image" all their developers worked with that same fresh system image (built from known archived sources).

(Perhaps I'm wrong about that.)

It was a bit of a combination. We tried using pre built images but managing them got out of hand pretty quickly and there was no easy way to diff images so whoever did it had to be careful.

Then we settled on pre built images with just the across team shared code. But that got difficult too, as some teams didn't want to upgrade as quickly as others on the shared code base, so we were maintaining several versions of that.

The teams themselves had regular image consolidations saved, plus file outs and some PVCS for those, but it got increasingly harder to make a consistent merged image no matter what and devs were spinning their wheels in a kind of code merge hell at the method level that is unique to smalltalk.

Then we got envy and it fixed everything.

ParcPlace did eventually come up with a different structure for packaging and sharing code but it was too late and too simplistic to be useful.

> … code merge hell at the method level … envy and it fixed everything.

Puzzled. ENVY/Developer is still Smalltalk and code merge still method level?

Perhaps what was shared within teams and between teams changed?

Yeah, there were a lot of side channels for sharing code that made merging things more difficult than they could have been. Poor discipline when devs were in a mad rush.

Seems to me that "sharing changes amongst your team members" is much more about process than it is about tools; and the process (whatever it is) must be followed by everyone every-time.

(With the benefit of hindsight) seems to me that many teams made their mistakes with vanilla Smalltalk and avoided those same mistakes when they moved to ENVY/Developer.

Envy enforced discipline in a way, which helped a lot. Sure, the devs could have had that discipline with filed out classes but because envy made sharing code easier, they inherited that process as well.

> … effectively impossible until they learned what they were doing due to the total scattergun approach a lot of them used.

You tell us the people didn't know what they were doing — so why blame the tools?

(Incidentally, I used Envy/Developer for years.)

I blame the tools because they were inadequate at the time and inferior to even rudimentary things like sccs.

Not every programmer is a superstar. Visual basic was a much better environment for average guys doing green screen replacement jobs.

> … replace a green screen in a team of 20 other programmers…

I was briefly involved with a project that sounds a bit like that — a 2 week training course for current staff, then rewrite everything from data model to U/X in half-the-usual time because someone said OO is more productive.

That project used ENVY/Developer. The staff admin deleted the repo. The staff wouldn't have passed phone screen for Smalltalk work (maybe some would have in 6 or 12 months). When the people don't know the basic tools, that's what matters.

It does help if they know the tools. The main struggle we had wasn't that they weren't smart, most of them were fantastic domain experts who just didn't have that inquisitive tech spark that sets different breeds of IT people apart. There is nothing wrong with being a domain expert who isn't that keen on cutting edge tools, but back then giving them smalltalk was a mistake. VB and powerbuilder were theoretically inferior, but far more productive for guys like that.