[TUHS] Anyone ever heard of teaching a case study of Initial Unix?

[TUHS] Anyone ever heard of teaching a case study of Initial Unix?

[Norman Wilson]

Steve Jenkin:

   I've never heard of a Computer Science or Software Engineering program
   that included a `case study' component, especially for Software
   Development & Projects.

[...]

  Creating Unix V6, because it profoundly changed computing & development,
  would seem an obvious Case Study for many aspects of Software, Coding
  and Projects.

====

How about the course for which John Lions wrote his famous
exegesis of the 6/e kernel?

Norman Wilson
Toronto ON

[TUHS] Re: Anyone ever heard of teaching a case study of Initial Unix?

[Clem Cole]

[-- Attachment #1: Type: text/plain, Size: 2474 bytes --]

On Wed, Jul 3, 2024 at 10:46 AM Norman Wilson <norman@oclsc.org> wrote:

> Steve Jenkin:
>
>    I've never heard of a Computer Science or Software Engineering program
>    that included a `case study' component, especially for Software
>    Development & Projects.
>
> [...]
>
>    How about the course for which John Lions wrote his famous
> exegesis of the 6/e kernel?
>
> Norman Wilson
> Toronto ON

This >>might<< be far from an OS >>developer<< perspective [*i.e*., for a
practitioner of SW development for an OS]. However, I'm quite sure it is
the same thing.    In Lion's case, he looks at the code and final system in
the same manner to examine the technical output/result  (a complete
timesharing system than in "modest HW", that a single person could
understand as it was less than 9000 KLOCs).   This is like an architecture
class might take apart drawings of Notre Dame Cathedral to examine how the
structure was developed to carry such huge loads of stone, wood, and lead
but still allow so much light in the building (such as the class on my CMU
roommates who became a restoration architect for buildings like 30th Street
Station in Philadelphia).  Case studies (which originated at HSB and are
now de rigor in most B-schools) look at the choices made, given a set of
initial conditions to create a (business) result [positively and
negatively].   What could be learned from the conditions, choices, and
results so that feature (business) leaders can recognize what might not be
obvious? The idea is that you are teaching managers about choices
that change/predict a future outcome.  This is not the same as field
practitioners trying to make a structure/machine/program to >>operate<< to
do some design function.

So, the place where a case study for SW projects (using books like Mythical
Man Month) would be helpful is an in-software engineering course. Writing
an HSB style case for something like UNIX, or Tenex or maybe Oracle;
particularly to compared to something like Brook's book would be
fascinating to read, I'm not sure Lion's text qualifies.   I think the
content of such a "case" would be quite different.

Again, it comes back to what "success" is. If success is defined as winning
the market, OS/360 was a huge success, as was DOS. But neither would
I consider a success from the standpoint of building something that future
generations of programmers would want to learn to emulate.
ᐧ
ᐧ

[-- Attachment #2: Type: text/html, Size: 4306 bytes --]

[TUHS] Re: Anyone ever heard of teaching a case study of Initial Unix?

[Clem Cole]

[-- Attachment #1: Type: text/plain, Size: 2732 bytes --]

s/be far/be fair/

Sorry, Grammerly rewrote that and I missed it with my dyslexia.
ᐧ
ᐧ

On Wed, Jul 3, 2024 at 11:45 AM Clem Cole <clemc@ccc.com> wrote:

>
>
> On Wed, Jul 3, 2024 at 10:46 AM Norman Wilson <norman@oclsc.org> wrote:
>
>> Steve Jenkin:
>>
>>    I've never heard of a Computer Science or Software Engineering program
>>    that included a `case study' component, especially for Software
>>    Development & Projects.
>>
>> [...]
>>
>>    How about the course for which John Lions wrote his famous
>> exegesis of the 6/e kernel?
>>
>> Norman Wilson
>> Toronto ON
>
> This >>might<< be far from an OS >>developer<< perspective [*i.e*., for a
> practitioner of SW development for an OS]. However, I'm quite sure it is
> the same thing.    In Lion's case, he looks at the code and final system in
> the same manner to examine the technical output/result  (a complete
> timesharing system than in "modest HW", that a single person could
> understand as it was less than 9000 KLOCs).   This is like an architecture
> class might take apart drawings of Notre Dame Cathedral to examine how the
> structure was developed to carry such huge loads of stone, wood, and lead
> but still allow so much light in the building (such as the class on my CMU
> roommates who became a restoration architect for buildings like 30th Street
> Station in Philadelphia).  Case studies (which originated at HSB and are
> now de rigor in most B-schools) look at the choices made, given a set of
> initial conditions to create a (business) result [positively and
> negatively].   What could be learned from the conditions, choices, and
> results so that feature (business) leaders can recognize what might not be
> obvious? The idea is that you are teaching managers about choices
> that change/predict a future outcome.  This is not the same as field
> practitioners trying to make a structure/machine/program to >>operate<< to
> do some design function.
>
> So, the place where a case study for SW projects (using books like
> Mythical Man Month) would be helpful is an in-software engineering course.
> Writing an HSB style case for something like UNIX, or Tenex or maybe
> Oracle; particularly to compared to something like Brook's book would be
> fascinating to read, I'm not sure Lion's text qualifies.   I think the
> content of such a "case" would be quite different.
>
> Again, it comes back to what "success" is. If success is defined as
> winning the market, OS/360 was a huge success, as was DOS. But neither
> would I consider a success from the standpoint of building something that
> future generations of programmers would want to learn to emulate.
> ᐧ
> ᐧ
>

[-- Attachment #2: Type: text/html, Size: 5600 bytes --]

[TUHS] Re: Anyone ever heard of teaching a case study of Initial Unix?

[Chet Ramey via TUHS]

[-- Attachment #1.1: Type: text/plain, Size: 1217 bytes --]

On 7/3/24 11:45 AM, Clem Cole wrote:

> So, the place where a case study for SW projects (using books like Mythical 
> Man Month) would be helpful is an in-software engineering course.Writing an 
> HSB style case for something like UNIX, or Tenex or maybe Oracle; 
> particularly to compared to something like Brook's book would be 
> fascinating to read, I'm not sure Lion's text qualifies. 

TENEX is a fascinating story.[1] An internal BBN project with a hardware
component, written by maybe half a dozen people.[2] It spread around the
country to research institutions kind of like Unix. DEC liked it so much
it bought TENEX and hired Dan Murphy away from BBN to turn it into
TOPS-20.[3]

[1] https://opost.com/tenex/tenex72.txt
[2] https://walden-family.com/bbn/10-SYS/
[3] https://opost.com/tenex/hbook.html

CWRU was a big DEC-20/TOPS-20 shop, and TOPS-20 was the first OS I used
when I started working for the computing center as a student (which evolved
into where I work today). I loved TOPS-20.

-- 
``The lyf so short, the craft so long to lerne.'' - Chaucer
		 ``Ars longa, vita brevis'' - Hippocrates
Chet Ramey, UTech, CWRU    chet@case.edu    http://tiswww.cwru.edu/~chet/


[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 203 bytes --]

[TUHS] Anyone ever heard of teaching a case study of Initial Unix?

[sjenkin]

I’ve never heard of a Computer Science or Software Engineering program
that included a ‘case study’ component, especially for Software Development & Projects.

MBA programs feature an emphasis on real-world ‘case studies’, to learn from successes & failures,
to give students the possibility of not falling into the same traps. 

Creating Unix V6, because it profoundly changed computing & development,
would seem an obvious Case Study for many aspects of Software, Coding and Projects.

There have been many descriptive treatments of Initial Unix,
but I’ve never seen a Case Study, 
with explicit lessons drawn, possibly leading to metrics to evaluate Project progress & the coding process.

Developers of Initial Unix arguably were 10x-100x more productive than IBM OS/360, a ‘best practice’ development at the time,
so what CSRC did differently is worth close examination.

I’ve not seen examined the role of the ‘capability’ of individual contributors, the collaborative, collegiate work environment 
and the ‘context’, a well funded organisation not dictating deadlines or product specifications for researchers.

USG, then USL,  worked under ’normal commercial’ management pressure for deadlines, features and specifications.

The CSRC/1127 group did have an explicit approach & principles for what they did and how they worked,
publishing a number of books & papers on them - nothing they thought or did is secret or unavailable for study.

Unix & Unix tools were deliberately built with explicit principles, such as “Less is More”.
Plan 9 was also built on explicit Design principles.

The two most relevant lessons I draw from Initial Unix are:

	- the same as Royce's original “Software Waterfall” paper, 
		“build one to throwaway” [ albeit, many, many iterations of the kernel & other code ]

	- Writing Software is part Research, part Creative ‘Art’:
		It’s Done when it's Done, invention & creation can’t be timetabled.

For the most reliable, widely used Open Source projects,
the “Done when it’s Done” principle is universally demonstrated.

I’ve never seen a large Open Source project succeed when attempting to use modern “Project Management” techniques.

These Initial Unix lessons, if correct and substantiated, should cause a revolution in the teaching & practice
of Professional Programming, i.e. Programming In the Large, for both CS & SW.

There are inherent contradictions within the currently taught Software Project Management Methodologies:

	- Individual capability & ability is irrelevant
		The assumption is ‘programmers’ are fungible/ identical units - all equally able to solve any problem.
		Clearly incorrect: course evaluations / tests demonstrate at least a 100x variance in ability in every software dimension.

	- Team environment, rewards & penalties and corporate context are irrelevant,
		Perverse incentives are widely evident, the cause of many, or all, “Death Marches”.

	- The “Discovery & Research Phases” of a project are timetabled, an impossibility.

Any suggestions for Case Studies gratefully accepted.

===========

Professions & Professionals must learn over time:

	 there’s a negative aspect (don’t do this) and positive aspect (do this) for this deliberate learning & improvement.

Negatives are “Don’t Repeat, or Allow, Known Errors, Faults & Failures” 
plus in the Time Dimension, “Avoid Delays, Omissions and Inaction”.

Positives are what’s taught in Case Studies in MBA courses: 

	use techniques & approaches known to work.

Early Unix, from inception to CACM papers, 1969 to 1974, took probably 30 man-years,
and produced a robust, performant and usable system for it’s design target, “Software Development”.

This in direct comparison to Fred Brooks IBM OS/360 effort around 5 years before that consumed 3,000-4,000 man-years
was known for bugs, poor & inconsistent code quality, needed large resource to run and was, politely, non-performant.

This was a commercial O/S, built by a capable, experienced engineering organisation, betting their company on it,
who assigned their very best to the hardware & software projects. It was “Best of Breed” then, possibly also now.

MULTICS had multiple business partners, without the same, single focus or commercial imperative.
I don’t believe it’s comparable to either system.

Initial Unix wasn’t just edit, compile & run, but filesystems, libraries, debugging & profiling tools, language & compiler construction tools, ‘man’ pages, document prep (nroff/troff) and 'a thousand' general tools leveraging shell / pipe.

This led directly to modern toolchains, config, make & build systems, Version Control, packaging systems, and more.
Nothing of note is built without using descendants or derivatives of these early toolchains.

All this is wrapped around by many Standards, necessary for portable systems, even based on the same platform, kernel and base system.

The “Tower of Babel” problem is still significant & insurmountable at times, even in C-C & Linux-Linux migration, 
but without POSIX/IEEE standards the “Software Tarpit” and "Desert of Despair” would’ve been unsolvable.

The early Unix system proved adaptable and extensible to many other environments, well beyond “Software Development”.

===========

[ waterfall model ]

Managing the development of large software systems: concepts and techniques
W. W. Royce, 1970 [ free access ]
	<https://dl.acm.org/doi/10.5555/41765.41801>

	STEP3: DO IT TWICE, pg 334

	After documentation, the second most important criterion for success revolves around whether the product is totally original.
	If the computer program in question is being developed for the first time, 
	arrange matters so that the version finally delivered to the customer for operational deployment 
	is actually the second version insofar as critical design/operations areas are concerned.

===========

Plan 9, Design

<https://9p.io/sys/doc/9.html>

The view of the system is built upon three principles. 
	First, resources are named and accessed like files in a hierarchical file system.
	Second, there is a standard protocol, called 9P, for accessing these resources. 
	Third, the disjoint hierarchies provided by different services are joined together into a single private hierarchical file name space. 

The unusual properties of Plan 9 stem from the consistent, aggressive application of these principles.

===========

Escaping the software tar pit: model clashes and how to avoid them
Barry Boehm, 1999 [ free access ]
	<https://dl.acm.org/doi/abs/10.1145/308769.308775#>

===========

Mythical Man-Month, The: Essays on Software Engineering, 
Anniversary Edition, 2nd Edition
Fred Brooks

Chapter 1. The Tar Pit

Large-system programming has over the past decade been such a tar pit, and many great and powerful beasts have thrashed violently in it.

===========
--
Steve Jenkin, IT Systems and Design 
0412 786 915 (+61 412 786 915)
PO Box 38, Kippax ACT 2615, AUSTRALIA

mailto:sjenkin@canb.auug.org.au http://members.tip.net.au/~sjenkin