From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: X-Spam-Checker-Version: SpamAssassin 3.4.4 (2020-01-24) on inbox.vuxu.org X-Spam-Level: X-Spam-Status: No, score=-0.8 required=5.0 tests=HEADER_FROM_DIFFERENT_DOMAINS, MAILING_LIST_MULTI autolearn=ham autolearn_force=no version=3.4.4 Received: from minnie.tuhs.org (minnie.tuhs.org [50.116.15.146]) by inbox.vuxu.org (Postfix) with ESMTP id 4C225277C5 for ; Wed, 3 Jul 2024 06:51:43 +0200 (CEST) Received: from minnie.tuhs.org (localhost [IPv6:::1]) by minnie.tuhs.org (Postfix) with ESMTP id 150E4427DF; Wed, 3 Jul 2024 14:51:38 +1000 (AEST) Received: from pasta.tip.net.au (pasta.tip.net.au [IPv6:2401:fc00:0:129::2]) by minnie.tuhs.org (Postfix) with ESMTPS id 74696427CA for ; Wed, 3 Jul 2024 14:51:23 +1000 (AEST) Received: from smtpclient.apple (203-7-124-164.dyn.iinet.net.au [203.7.124.164]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by mailhost.tip.net.au (Postfix) with ESMTPSA id 4WDS6G5Drnz9R41; Wed, 3 Jul 2024 14:51:16 +1000 (AEST) From: sjenkin@canb.auug.org.au Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable Mime-Version: 1.0 (Mac OS X Mail 16.0 \(3774.600.62\)) Date: Wed, 3 Jul 2024 14:51:01 +1000 Message-Id: <93529CA0-7097-443C-999B-384BE6BD5683@canb.auug.org.au> To: TUHS X-Mailer: Apple Mail (2.3774.600.62) Message-ID-Hash: LWVTUW7NZSKHUVLZDSBJIUR7KQLIB2IT X-Message-ID-Hash: LWVTUW7NZSKHUVLZDSBJIUR7KQLIB2IT X-MailFrom: sjenkin@canb.auug.org.au X-Mailman-Rule-Misses: dmarc-mitigation; no-senders; approved; emergency; loop; banned-address; member-moderation; header-match-tuhs.tuhs.org-0; nonmember-moderation; administrivia; implicit-dest; max-recipients; max-size; news-moderation; no-subject; digests; suspicious-header X-Mailman-Version: 3.3.6b1 Precedence: list Subject: [TUHS] Anyone ever heard of teaching a case study of Initial Unix? List-Id: The Unix Heritage Society mailing list Archived-At: List-Archive: List-Help: List-Owner: List-Post: List-Subscribe: List-Unsubscribe: I=E2=80=99ve never heard of a Computer Science or Software Engineering = program that included a =E2=80=98case study=E2=80=99 component, especially for = Software Development & Projects. MBA programs feature an emphasis on real-world =E2=80=98case studies=E2=80= =99, to learn from successes & failures, to give students the possibility of not falling into the same traps.=20 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=E2=80=99ve never seen a Case Study,=20 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 =E2=80=98best practice=E2=80=99 development at the time, so what CSRC did differently is worth close examination. I=E2=80=99ve not seen examined the role of the =E2=80=98capability=E2=80=99= of individual contributors, the collaborative, collegiate work = environment=20 and the =E2=80=98context=E2=80=99, a well funded organisation not = dictating deadlines or product specifications for researchers. USG, then USL, worked under =E2=80=99normal commercial=E2=80=99 = 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 =E2=80=9CLess is More=E2=80=9D. 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 =E2=80=9CSoftware Waterfall=E2=80=9D= paper,=20 =E2=80=9Cbuild one to throwaway=E2=80=9D [ albeit, many, = many iterations of the kernel & other code ] - Writing Software is part Research, part Creative =E2=80=98Art=E2= =80=99: It=E2=80=99s Done when it's Done, invention & creation = can=E2=80=99t be timetabled. For the most reliable, widely used Open Source projects, the =E2=80=9CDone when it=E2=80=99s Done=E2=80=9D principle is = universally demonstrated. I=E2=80=99ve never seen a large Open Source project succeed when = attempting to use modern =E2=80=9CProject Management=E2=80=9D = 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 =E2=80=98programmers=E2=80=99 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, =E2=80=9CDeath Marches=E2=80=9D. - The =E2=80=9CDiscovery & Research Phases=E2=80=9D of a project = are timetabled, an impossibility. Any suggestions for Case Studies gratefully accepted. =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D Professions & Professionals must learn over time: there=E2=80=99s a negative aspect (don=E2=80=99t do this) and = positive aspect (do this) for this deliberate learning & improvement. Negatives are =E2=80=9CDon=E2=80=99t Repeat, or Allow, Known Errors, = Faults & Failures=E2=80=9D=20 plus in the Time Dimension, =E2=80=9CAvoid Delays, Omissions and = Inaction=E2=80=9D. Positives are what=E2=80=99s taught in Case Studies in MBA courses:=20 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=E2=80=99s = design target, =E2=80=9CSoftware Development=E2=80=9D. 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 = =E2=80=9CBest of Breed=E2=80=9D then, possibly also now. MULTICS had multiple business partners, without the same, single focus = or commercial imperative. I don=E2=80=99t believe it=E2=80=99s comparable to either system. Initial Unix wasn=E2=80=99t just edit, compile & run, but filesystems, = libraries, debugging & profiling tools, language & compiler construction = tools, =E2=80=98man=E2=80=99 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 =E2=80=9CTower of Babel=E2=80=9D problem is still significant & = insurmountable at times, even in C-C & Linux-Linux migration,=20 but without POSIX/IEEE standards the =E2=80=9CSoftware Tarpit=E2=80=9D = and "Desert of Despair=E2=80=9D would=E2=80=99ve been unsolvable. The early Unix system proved adaptable and extensible to many other = environments, well beyond =E2=80=9CSoftware Development=E2=80=9D. =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D [ waterfall model ] Managing the development of large software systems: concepts and = techniques W. W. Royce, 1970 [ free access ] 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,=20 arrange matters so that the version finally delivered to the = customer for operational deployment=20 is actually the second version insofar as critical = design/operations areas are concerned. =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D Plan 9, Design The view of the system is built upon three principles.=20 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.=20 Third, the disjoint hierarchies provided by different services = are joined together into a single private hierarchical file name space.=20= The unusual properties of Plan 9 stem from the consistent, aggressive = application of these principles. =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D Escaping the software tar pit: model clashes and how to avoid them Barry Boehm, 1999 [ free access ] =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D Mythical Man-Month, The: Essays on Software Engineering,=20 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. =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D -- Steve Jenkin, IT Systems and Design=20 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