[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: Modern computer users sent back in time...

Sir Fart A Lot wrote (>)  and Mike W. wrote (>>):


1) smaller bureaucracies
That seems wrong. Buraucracies were around 30 years ago or 300 years ago for that matter. Only a certain percentage of the folks out there can do something, everyone else has to look busy. This is not unique or a growing phenomena in our generation any more than before. 

But the bureaucracy grows (often superlinearly) with the size and
complexity of the project, and in for both hardware and software
projects, those have both exploded in the last couple of decades.

Therefore, from a theoretical basis, one would expect his premise to
be true:  there used to be much smaller bureaucracies for hardware
and software projects.

From experience, this is certainly true.  In the 1960's and 1970's,
the norm for complete software projects (OS's, compilers, applications)
was individuals or small teams (5 or less members).  They were given
objectives and were allowed to execute with little outside interference.

It was like heaven compared to the modern norm!


    2) less complex projects that might actually work the first time
This is wrong too. The projects may seem less complex but were in fact every bit as complex if not more so due to the tools at your disposal. Your forgetting what sort of hardware/user interface you will have in these older systems which adds to the complexity of your job. Hindsight is 20/20, but remember you cant bring a laptop from the present back with you. 

You didn't need one.  You had the entire machine to yourself to develop
on--though sometimes from midnight to 4 a.m.  ;-)

Tools were simpler, libraries were almost non-existent, so you did
everything yourself--and you kept the complexity down, because if you
didn't you knew you would fail.

I do agree that human beings generally allow complexity to rise to just
over their heads (to keep things challenging ;-), but after a bit of
painful experience, successful people learn to control that impulse and
keep it manageable.

The problem today, compared to the 1960's, is that today the project
team *cannot* fully control the complexity, much of which is extrinsic
to the project itself, in the environment, the OS, the megabytes of
libraries, the meetings, the meetings, the meetings, etc.


    3) less complex projects that one person could actually understand
I think this depends on where you are working and what your working on. None the less, the same situation exists today for the same reasons although I think it is rare. A good point would be a little later in time. say the 1970's with game developers for Atari writing the whole games individually. That is a pretty fascinating and wonderful way for a programmer to create a piece of art and call it his own. It can happen these days especially with the casual games and embedded markets, but you have to seek it out (which is probably no different than before as Atari and Colecto etc. programmers were rare). 

Of course, you are correct that "it depends".  But there were very few
active projects to "boil the ocean" in the 1960's--most computer folks
were not captive to grandiose business plans or national air defense
objectives.

A very large proportion of projects then were more self-contained, and
suited to individual contribution and rewards.  Craftsmanship and art
were the hallmarks of the profession.


    4) less complex projects that you could complete in less than a year
Same as #3. Some projects took many years. I think your grossly underestimating the complexity and comparing to now as if you were going to do the same project with the tools you have now. 

Nope--been there, done that.  Learned never to try to boil the ocean.
Always fit the project complexity to the tools and brain working set.

Occasionally fail (and learn plenty), mostly succeed.

This included projects like an interactive OS, and three interactive
graphical data analysis systems--all either individual or with teams
of 3-4 people.  Small memories and slow processors clarify the mind
wonderfully.
5) happier customers because most products actually work without random failures after 3 months of time
Thats a fantasy. The good old days had problems too and they were usually very proprietary and expensive to fix. And they weighed more! 

Of course, the "heavy" ones had lots of support, and often an on-site
customer engineer!

The "light" ones are always the problem, because there tend to be
many thousands of them in the hands of relatively untrained users,
and no support in sight.  ;-)

But in the 1960's any digital application small and inexpensive
enough to have many thousands of copies was usually simple enough
to design properly and test thoroughly.  Not so likely today, with
megabytes of code in your handheld device.


    6) customers that will pay for special one-off projects
Some customers do that now. In fact , my years at IBM showed me that most new research is funded at least in part by a particular customer needing something. This is happening today. 



    7) smaller, more focused teams
This is the same as #2. It depends on where you would be working. My uncle worked at Bell Labs from after World war II till the 60's when he joined Hughes Aircraft. He was on the team that developed the transistor as well as commercial satellite technologies. The teams ranged from 10 guys to fairly large teams of thousands. 

Let me guess:  the transistor was developed by a small team, the
satellite systems by teams of thousands.  ;-)

There's no better way to get a complex problem than by joining together
hundreds of different technologies, each requiring their own expertise,
in a single project.  Satellites are a great example of that.

From my own experience, though such projects are important and valuable,
they require great personal sacrifice on the part of their participants,
who are denied any comprehensive understanding of the problem or its
solution, must endure endless objective shifts caused by interactions
over which they have no control, and can only experience "success" in
a very indirect and vicarious way.

Given a choice, I'd take the smaller, more focused project everytime--
with its inescapable accountability and tangible success (or failure).
9) regular working hours (you can find your team-mate when you need him or her) 


Skunk works.


Yes, I'm not sure I would have said "regular", since much of my work on
very innovative and interesting projects was done "off shift"!  But when
a small team is involved, it is easy to coordinate schedules and pass
results back and forth.  This is what the "project logbook" was created
to do!



Regards,
Mike W.

N.N. Thayer wrote:


Here's a question that's bounced around in my head for a while.

The scenario is: take a bunch of programmers, system administrators,
hardware techies, et cetera and unceremoniously dump them in the
1960's.  They come only with their existing knowledge, and must adjust
it accordingly if they are to continue along their line of work.
Assume that situational side-concerns such as money, ID, and living
space are irrelevant.

What is the manner of this acclimation to a previous generation of
technology?  What challenges are faced?  Would someone in a specific
occupation, such as a programmer, be more likely to pass the
inevitable weeding process?


-michael

NadaPong: Network game demo for Apple II computers!
Home page:  http://members.aol.com/MJMahon/

"The wastebasket is our most important design
tool--and it's seriously underused."