Hopper Urges Multicomputer Systems as Speed of Light Halts Chip Gains

National Security Agency

Physical speed-of-light limits prevent single processors from scaling beyond picosecond cycles, making distributed networks of cheap microcomputers the only viable path to meet surging computational demands.

AI-assisted summary of Capt. Grace Hopper on Future Possibilities: Data, Hardware, Software, and People (Part One, 1982) — original source. Check the original for full context.

Source published: 2024-08-26

Key ideas

Grace Hopper warns that computing is repeating the systemic errors of the transportation industry by fixating on isolated hardware rather than analyzing broader information flow and evaluating the intrinsic value of processed data. (5:56)
Poor data quality carries major financial and legal liability under federal statutes such as the Privacy Act, where a modeled 5% error rate across 8,000 personnel records yielded an estimated $495,000 in potential agency damages. (13:12)
Computational speed increases face physical limits imposed by the speed of light at picosecond cycle times, necessitating distributed multi-computer architectures rather than increasingly larger monolithic processors. (44:26)
Physical teaching aids—such as 11.8-inch wires representing a light-nanosecond and molecular ball-and-stick modeling kits—are essential tools for communicating circuit latency and complex three-dimensional distributed system topologies. (40:04)

Detailed notes

## Background Published on YouTube by the National Security Agency on August 26, 2024, this video captures Part One of Captain Grace Hopper's 1982 presentation titled "Future Possibilities: Data, Hardware, Software, and People." Delivered at the NSA, the lecture offers Hopper's historical and forward-looking perspectives on the management of data, computing machinery, and human organizations.

## TL;DR Captain Grace Hopper draws upon her decades of naval computing experience—dating back to the Harvard Mark I—to warn that the industry risks repeating the mistakes of the transportation sector by obsessing over hardware tools rather than the value, flow, and integrity of data. She argues that organizations must rigorously purge stale online records and account for the substantial legal liabilities created by inaccurate information. Facing the physical limits imposed by the speed of light, Hopper asserts that the future of computing lies not in building bigger single processors, but in networking systems of cheap, distributed microcomputers. Throughout her talk, she champions junior initiative, urging practitioners to discard bureaucratic inertia and use common sense to solve technical bottlenecks.

## Atmosphere & style Hopper delivers a sharp, folksy, and disarmingly funny performance that balances commanding naval authority with mischievous irreverence toward rigid bureaucracy. Speaking with crisp timing and self-deprecating wit, she captivates her defense audience through tactile demonstrations and tangible props—from 11.8-inch nanosecond wires to counterclockwise office clocks and Tinker Toy models. Listening to her feels like being let in on practical trade secrets by a seasoned pioneer who effortlessly cuts through abstract engineering jargon with common sense and historic war stories.

## Bulletin - [05:56](https://www.youtube.com/watch?v=si9iqF5uTFk&t=356s) Grace Hopper warns that computing is repeating the systemic errors of the transportation industry by fixating on isolated hardware rather than analyzing broader information flow and evaluating the intrinsic value of processed data. - [13:12](https://www.youtube.com/watch?v=si9iqF5uTFk&t=792s) Poor data quality carries major financial and legal liability under federal statutes such as the Privacy Act, where a modeled 5% error rate across 8,000 personnel records yielded an estimated $495,000 in potential agency damages. - [44:26](https://www.youtube.com/watch?v=si9iqF5uTFk&t=2666s) Computational speed increases face physical limits imposed by the speed of light at picosecond cycle times, necessitating distributed multi-computer architectures rather than increasingly larger monolithic processors. - [40:04](https://www.youtube.com/watch?v=si9iqF5uTFk&t=2404s) Physical teaching aids—such as 11.8-inch wires representing a light-nanosecond and molecular ball-and-stick modeling kits—are essential tools for communicating circuit latency and complex three-dimensional distributed system topologies.

## Key takeaways - [00:39](https://www.youtube.com/watch?v=si9iqF5uTFk&t=39s) The United States' first large-scale digital computer was developed and operated by the U.S. Navy during World War II. - [03:07](https://www.youtube.com/watch?v=si9iqF5uTFk&t=187s) Henry Ford's introduction of interchangeable parts and assembly lines sparked mass automobile adoption, but over-focusing on cars led to the neglect of national railroad infrastructure. - [05:56](https://www.youtube.com/watch?v=si9iqF5uTFk&t=356s) The computer sector is entering its 'Model T' era through microcomputers, requiring a fundamental shift in focus from hardware machinery to total information flow. - [05:56](https://www.youtube.com/watch?v=si9iqF5uTFk&t=356s) Information value must be systematically evaluated based on action windows, human lives at stake, financial impact, and executive decision relevance rather than whoever complains loudest. - [08:43](https://www.youtube.com/watch?v=si9iqF5uTFk&t=523s) Organizations fall into an online prestige trap by keeping entire inactive datasets instantly accessible instead of tiering older records into batch or archival storage. - [11:40](https://www.youtube.com/watch?v=si9iqF5uTFk&t=700s) Information value peaks rapidly after an event while maintenance and storage costs compound over time, creating a crossover threshold where holding data online costs more than it is worth. - [13:12](https://www.youtube.com/watch?v=si9iqF5uTFk&t=792s) A case study from Maxwell Air Force Base demonstrates that civil liability under the Privacy Act for inaccurate personnel records provides a quantifiable financial justification for investing in data cleansing. - [17:47](https://www.youtube.com/watch?v=si9iqF5uTFk&t=1067s) The original computer bug—a moth trapped in a signal relay of the Harvard Mark II in 1945—remains preserved in a logbook at the Naval Surface Warfare Center museum. - [22:39](https://www.youtube.com/watch?v=si9iqF5uTFk&t=1359s) Sound strategic planning requires evaluating against all future contingencies and calculating the cost of not executing a plan, rather than reflexively doing things the way they have always been done. - [25:33](https://www.youtube.com/watch?v=si9iqF5uTFk&t=1533s) Bureaucratic inertia should be bypassed by taking initiative and begging forgiveness afterward, as a supervisor's initial refusal is often a reflexive barrier rather than a sound technical judgment. - [27:35](https://www.youtube.com/watch?v=si9iqF5uTFk&t=1655s) Grassroots adoption of commercial off-the-shelf microcomputers by enlisted sailors significantly outperformed top-down IT procurement and established the Navy Regional Data Center Micro Evaluation Group. - [33:44](https://www.youtube.com/watch?v=si9iqF5uTFk&t=2024s) Computational addition speeds improved exponentially from 333 milliseconds on early machines to 282 microseconds on the UNIVAC I, 300 nanoseconds on the CDC 6400, and an ultimate target of 300 picoseconds. - [35:15](https://www.youtube.com/watch?v=si9iqF5uTFk&t=2115s) Massive computational throughput is critically required to model global ocean-atmosphere heat engines and manage continental water allocation crises before environmental disasters occur. - [38:49](https://www.youtube.com/watch?v=si9iqF5uTFk&t=2329s) Small municipal governments and local businesses require microcomputers to manage complex, schema-divergent regulatory reporting mandates imposed by federal and state agencies. - [40:04](https://www.youtube.com/watch?v=si9iqF5uTFk&t=2404s) Physical props make abstract time scales tangible, using an 11.8-inch wire to represent the distance electricity travels in a nanosecond and ground pepper specks to illustrate picoseconds. - [44:26](https://www.youtube.com/watch?v=si9iqF5uTFk&t=2666s) Hitting the speed-of-light barrier at sub-nanosecond intervals requires scaling systems horizontally by adding more computers, analogous to hitching a second ox rather than trying to breed a giant one. - [46:24](https://www.youtube.com/watch?v=si9iqF5uTFk&t=2784s) Distributed multicomputer networks cannot be effectively represented on flat two-dimensional flowcharts and require three-dimensional physical models, such as chemistry molecular modeling sets.

## Detailed walkthrough ### [00:39](https://www.youtube.com/watch?v=si9iqF5uTFk&t=39s) The First Computer, Identifiers, and Airport Mix-ups

Captain Grace Hopper opens her talk by emphasizing her appreciation for the introduction, as it provides a prime opportunity to set the historical record straight. The very first large-scale digital computer in the United States was a Navy computer operated by a Navy crew during World War II. Hopper explains that she constantly has to remind audiences of this historical fact because a “certain junior service” repeatedly attempts to claim credit for early computing achievements—even though that service did not even exist when the work occurred. Turning to her uniform, she explains why she keeps her military cap on during the start of a talk: it serves as her identifier, comparing it directly to database architecture. Just as every record in a computer system requires a key identifier so the system knows where to store it and how to retrieve it, people rely on external identifiers, though both the creator and the reader must understand them.

That shared understanding, Hopper laments humorously, often breaks down in everyday life. While walking through airports in her Navy uniform, travelers constantly walk up to her asking when the next flight leaves for Houston. Her most humbling encounter occurred late one night in San Francisco, when an elevator companion whispered to her husband, "What was that?", and he replied that she was a security guard. Another memorable encounter occurred at immigration at the Toronto airport on her way to speak at the University of Guelph. The Canadian immigration officer examined her passport, stared at her, and bluntly asked, "What are you?" When Hopper answered that she was United States Navy, he took a hard second look and told her she must be the oldest one they have.

- Hopper retorted to the immigration officer by pointing out that Admiral Hyman Rickover was six years older, though she doubted the officer even recognized the name. - Removing her cap to reveal her white hair, Hopper remarked: “It’s because it gives me an opportunity to remind you that the first large scale digital computer in the United States was a Navy computer, operated by Navy crew during World War Two.”

---

[03:07](https://www.youtube.com/watch?v=si9iqF5uTFk&t=187s) Henry Ford's Model T and the Parable of the Transportation System

Hopper shifts into an extended historical parallel drawn from her childhood. She recalls living by Riverside Drive along the Hudson River in New York City when it was still an unpaved dirt road. On Sunday afternoons, her family would sit and watch horses and carriages pass; seeing a single automobile in an entire afternoon was a rarity. At that time, cars were custom-built luxury items. There were no gas stations; long trips required strapping five-gallon cans of gasoline onto the car's back deck. If an automobile broke down in Utah, the driver had to telegraph the manufacturer, who would dispatch a mechanic with a raw part that had to be hand-tooled until it fit that specific vehicle.

Everything shifted when Henry Ford introduced two foundational concepts: standard interchangeable parts and the moving assembly line to produce the Model T. Priced between $300 and $600, the Model T made automobile ownership accessible to the masses. Hopper traces the domino effect that reshaped modern society: car ownership drove demands for paved roads, which brought filling stations, repair shops with standardized parts, suburban communities, and ultimately regional shopping centers.

```mermaid flowchart TD accTitle: Ford Model T Societal Impact Flow accDescr: Diagram tracing the cascading societal effects of Henry Ford's mass production methods. subgraph MassProduction["Mass Production Foundations"] A["Standard Interchangeable Parts"] B["Moving Assembly Line"] end subgraph Adoption["Automobile Adoption"] C["Affordable Model T ($300-$600)"] D["Mass Ownership of Cars"] end subgraph Infrastructure["Infrastructure & Society"] E["Paved Road Demand & Gas Stations"] F["Suburbanization & Daily Commuting"] G["Shopping Centers & Modern Lifestyle"] end A --> C B --> C C --> D D --> E E --> F F --> G ```

However, this unchecked focus on automobiles produced a grave systemic blind spot. In obsessing over cars, the nation neglected total transportation management. As a result, the railroad beds fell apart, leaving the country ill-prepared for national logistics: - Flat cars were abandoned because automobiles are shipped across highways on carrier racks, leaving the military without sufficient flat cars to move heavy tanks from the interior to coastal ports for overseas deployment. - A critical shortage of hopper cars means the nation cannot simultaneously transport massive grain harvests and move coal to offset oil dependency. - Hopper issues a stern warning about repeating these systemic mistakes: “And the truth of the matter is we’ve done a lousy job of managing transportation as a whole.”

---

[05:56](https://www.youtube.com/watch?v=si9iqF5uTFk&t=356s) Information Flow over Hardware and the Unmeasured Value of Data

Drawing a direct analogy to the computer industry, Hopper declares that the arrival of the microcomputer marks the "Model T" era of computing. The industry has finished its preliminary phases and is entering what will become the largest industry in the United States. Yet, she fears computer professionals are repeating the transportation mistake by fixating on isolated hardware pieces and layering code over them, rather than analyzing the overarching flow of information across organizations. To architect systems properly, organizations must first analyze information flow and understand the intrinsic value of the data being processed.

Hopper recounts that for roughly eight years, she had been asking industry practitioners how they assign value to their information, only to receive blank stares. Her early hypothesis—that system execution priorities reflected data value—proved false. Priorities are routinely assigned to whoever complains the loudest, or as she phrases it, “the senior squeaky wheel.” To prove that information has vastly divergent values, Hopper details an automated chemical plant in Michigan where computing systems control marketing, manufacturing valves, automated inventory, payroll, and executive reporting:

Hopper proposes four concrete criteria for evaluating information: 1. The window of time within which action must be taken. 2. The number of human lives affected. 3. The dollar value at stake. 4. The significance of the information in driving executive decisions.

Hopper emphasizes that data volume is expanding nonlinearly while demand for instantaneous online access is escalating exponentially. Because these two forces are directly in conflict, the industry can no longer avoid evaluating data worth: “Cause there are two things that are dead sure; I don’t even have to call them predictions. One is that the amount of data and the amount of information will continue to increase, and it’s more than linear. And the other is the demand for instant access to that information will increase.”

---

[08:43](https://www.youtube.com/watch?v=si9iqF5uTFk&t=523s) The Online Prestige Trap and Truncating Records for Speed

Hopper critiques the organizational obsession with placing every record online, noting it often stems from internal rivalry and prestige rather than genuine operational necessity. She shares an experiment she performed on an activity where everyone clamored for immediate online access. She quietly embedded a hidden counter into every single record to monitor how often it was fetched. After six months, she generated a report of records that had zero reads; an entire master file fell out unused, exposing that its presence online served purely as an executive vanity metric.

Fortunately, some forward-thinking military organizations have started assessing data through its time value and restructuring databases accordingly:

- **The U.S. Coast Guard:** They maintained a massive maintenance history file for every navigational buoy. Historically begun on punch cards, these individual records had grown bloated over decades, severely degrading system response times. Recognizing that field tenders servicing buoys only require maintenance entries from the preceding couple of years, the Coast Guard split the records. The active recent history remains online for fast lookup, while the older acquisition and historical cost records were relegated to batch storage, retrievable within a day or two when budgeting for replacements. - **Tactical Air Command at Langley:** The command historically kept the complete career history of personnel online for base assignments, which dragged the entire system down. Upon review, administrators realized that personnel officers making base assignments only care about recent assignments and recent service schools, not where a service member attended high school. They truncated the online profile to immediate relevant history and moved deeper archival records—needed only for occasional medal evaluations or promotions—back to overnight batch retrieval.

Hopper concludes this section by urging broader academic and industrial research into time-value and comparative data valuation: “Nobody is looking at the value of information or comparative value of different pieces of information, and we’ve got to look at it because it’s cutting up our online systems.”

[11:40](https://www.youtube.com/watch?v=si9iqF5uTFk&t=700s) The Value and Cost Curves of Information

Captain Grace Hopper illustrates the lifecycle of information by sketching hypothetical curves for value and cost over time. When an event occurs, the value of information regarding that event climbs sharply almost immediately. Over time, that value levels off until the data is either superseded by newer information or deemed non-essential for active systems and transferred into historical archives, microfilms, or preserved for legal obligations like the Internal Revenue Service.

Conversely, the cost curve starts exceptionally low at the moment of the event. As time passes, the cumulative expenses required to store, maintain, and update that information mount, causing the cost curve to surge upward. This dynamic inevitably produces a critical crossover point. Hopper highlights that organizations are virtually blind to where this intersection lies, leaving them unable to determine when data stops being useful and begins draining resources.

```mermaid flowchart LR accTitle: Information Value and Cost Over Time accDescr: Diagram showing the diverging trajectories of information value and maintenance cost leading to a crossover point.

subgraph Timeline["Information Lifecycle"] E["Event Occurs"] --> P["Peak Operational Value"] P --> L["Value Levels Off"] L --> A["Archive / Historical Storage"] end

subgraph Economics["Economic Dynamics"] C1["Initial Cost: Very Low"] --> C2["Accumulated Storage & Maintenance"] C2 --> X["Crossover Point: Cost Exceeds Value"] end

Timeline -.-> Economics ```

As Hopper emphasizes, the inability to quantify these variables prevents organizations from effectively purging their online architectures: “Now there’s a lovely crossover point there—that’s the point at which keeping that information in our online system is costing us more than it’s worth to us.” Because computer scientists and administrators have not conducted the necessary research to locate that threshold, systems remain cluttered with stale data.

- **Information Value Trajectory:** Rises sharply immediately following an event, plateaus over time, and eventually falls as data is archived or replaced. - **Information Cost Trajectory:** Starts negligible at the time of the event and escalates continuously as maintenance, storage, and updates accumulate. - **The Crossover Dilemma:** Without concrete figures on value versus maintenance expense, systems lack an objective basis for purging online records to historical storage.

---

[13:12](https://www.youtube.com/watch?v=si9iqF5uTFk&t=792s) Quantifying the Cost of Bad Data: The Maxwell AFB Case Study

Turning from storage costs to data integrity, Hopper observes that organizations rarely compute the tangible liabilities generated by incorrect records. She recounts an investigation conducted by Lieutenant Colonel Randleman at Maxwell Air Force Base, who examined the Privacy Act to uncover the financial repercussions of poor data quality. Randleman discovered a provision granting federal employees the right to file civil suits against agencies if adverse decisions regarding promotions, raises, or qualifications stem from inaccurate, outdated, irrelevant, or incomplete records. Hopper calls the statutory phrasing—“accuracy, relevance, timeliness, and completeness”—four extraordinarily potent words, providing one of the rare avenues for citizens to sue the government directly in U.S. District Court.

To model the real-world exposure of bad records, Randleman formulated a mathematical scenario based on a hypothetical personnel roster of 8,000 individuals:

```mermaid flowchart TD accTitle: Liability Model for Erroneous Personnel Records accDescr: Step-by-step calculation showing how inaccurate personnel records translate into civil liability costs.

Randleman assumed the file was 95% accurate—an optimistic figure, since Hopper remarks that she does not believe a single personnel file in the United States achieves 95% correctness. Even at that rate, 400 individuals possessed flawed records. Personnel evaluators and psychologists confirmed that irregularities stand out and almost always prompt an adverse determination; in roughly 90% of those cases (360 individuals), a negative decision would be rendered. Randleman then applied a conservative 50% probability that the wronged employees would file suit, yielding 180 legal claims against the federal agency.

Given that the errors exist in the files, the government would inevitably lose these suits. Estimating conservative damages of $2,000 alongside $100 for court costs and $650 for legal fees, each claim would cost the agency $2,750. Multiplying 180 claims by $2,750 yields an aggregate liability of $495,000—nearly half a million dollars at stake across just 8,000 records. Hopper underlines the managerial consequence of this calculation: “Now until we make that computation of the possible cost of incorrect information, we can’t make a clear estimate of how much we are willing to spend to correct the file.” Understanding the potential losses gives leadership the financial justification to invest heavily in data cleansing.

---

[17:02](https://www.youtube.com/watch?v=si9iqF5uTFk&t=1022s) Refocusing on the Data: Tools Versus Products

Reflecting on the history of the computing industry, Hopper laments that thirty years have been squandered obsessing over processing mechanisms while neglecting the underlying material. Hardware and software, she insists, are merely the machinery used to manipulate data, not the objective itself. The industry has elevated the tools above the actual substance and product.

Hopper lays out this fundamental distinction with unmistakable clarity: “And yet the data is our raw material—our output is information, our product—and we should be concentrating on the data and the information.” She insists that computing professionals must fundamentally shift their priorities away from the machinery and toward the integrity, validity, and utility of the information being generated, promising to continue campaigning for this shift despite the difficulty of changing minds.

---

[17:47](https://www.youtube.com/watch?v=si9iqF5uTFk&t=1067s) The First Computer Bug and Early Artifacts

Connecting past realities to modern computing concepts, Hopper reminisces about operating the Harvard Mark series computers during World War II. During the sweltering summer of 1945, her team was assembling the Mark II inside a World War I temporary building in Cambridge, Massachusetts. The facility lacked both screens on the windows and adequate air conditioning. When the Mark II unexpectedly malfunctioned, the crew methodically tested components until they pinpointed a massive failed signal relay.

Inside the relay, beaten to death by the mechanical contacts, was a moth. An operator used tweezers to extract the insect, affixed it into the system logbook using Scotch tape, and penned the caption: *“First actual bug found.”*

Hopper points out that the moth remains preserved beneath that tape to this day, housed at the Naval Surface Warfare Center museum in Dahlgren, Virginia. When members of the American Federation of Information Processing Societies (AFIPS) cast doubt on the legend, they made an expedition to Dahlgren, verified the relic in the logbook, and published a photograph of it in the July 1981 issue of the *Annals of the History of Computing*. Hopper delivers a dry, humorous reflection on her own longevity in the service: “And I think it’s rather nice that the Navy is keeping a few of the early artifacts like the first bug and me and a few other things.”

---

[19:16](https://www.youtube.com/watch?v=si9iqF5uTFk&t=1156s) “Too Old” at Forty and Naval War College Problems

With the conclusion of World War II in 1946, the Navy gave members of the WAVES (Women Accepted for Volunteer Emergency Service), who had entered as reservists, the opportunity to transfer into the regular Navy. Hopper applied immediately, only to be rejected because the age ceiling was 38 and she had already turned 40. She offers a characteristically resilient perspective on the rejection, advising that experiencing such a setback at forty desensitizes a person to aging forever after. Electing to remain in the Naval Reserve, she had to fulfill the required drills, two weeks of annual active duty, and specialized correspondence courses.

Initially designated as an ordnance officer—before a later administrative reorganization arbitrarily reclassified her as an aeronautical engineer—she consumed every available post-war ordnance manual, learning details about obsolete gun turrets and naval rifles until the courses were exhausted. The only remaining eligible courses carrying credit for her designator were offered by the Naval War College. Terrified by the advanced tactical curriculum, she opened her first War College scenario: she was instructed to fuel an entire task force at sea in minimum time, equipped solely with the pumping and receiving capacities of each ship type.

Having no maritime logistics experience, Hopper relied on basic logic and principles from problem-solving courses:

- **Simultaneous Transfers:** Seeing that oilers could pump to aircraft carriers faster than carriers could receive, she rigged fuel lines from the oiler to the carrier and simultaneously from the carrier to an accompanying destroyer. - **Extending the Solution:** Recalling an instruction to always extend every solution, she directed the destroyer to pump fuel concurrently into an adjacent corvette. - **Generalizing the Solution:** Applying the rule to generalize solutions, she duplicated the arrangement on the starboard side of the oiler with a cruiser, a destroyer, and another corvette.

Hopper notes that she ended up with nearly half a task force linked together by fueling hoses steaming in unison down the open ocean. Her assignment came back graded with the dry notation: *“An interesting solution.”* Unperturbed, she proceeded to the second War College assignment, which tasked her with scouting the Caribbean Sea using a submarine squadron in minimum time. Knowing even less about submarines than oilers, Hopper bypassed conventional maritime doctrine, wrote a random walk program for a digital computer, and simulated their trajectories across the map to blanket the area in minimum time.

[22:39](https://www.youtube.com/watch?v=si9iqF5uTFk&t=1359s) Planning for the Future and the Counterclockwise Clock

Grace Hopper recalls completing tactical problem sets for the Naval War College. Her submarine routing solutions were unconventional: “I had those submarines cutting across each other; they made U-turns, one did a little circle up here and came back.” The third assignment was the most critical: formulating an operational plan to capture an island. That assignment required two compulsory reviews: evaluating the plan against every possible enemy action and future event, and reviewing the cost of not carrying out the plan at all. Hopper points out that these two vital steps are routinely omitted from contemporary computer planning, where organizations blindly project present operations onto installed hardware instead of anticipating future needs and technological capabilities.

```mermaid flowchart TD accTitle: Two Reviews for Operational and Computer Planning accDescr: Grace Hopper's two-step review process derived from Naval War College planning exercises applied to computer systems.

subgraph Planning["Plan Formulation"] P["Draft Plan (Take Island / Deploy Computers)"] end

subgraph Reviews["Mandatory Reviews"] R1["Review 1: All Possible Future Events & Enemy Actions"] R2["Review 2: Cost of Not Carrying Out the Plan"] end

subgraph Outcome["Outcome"] F["Adaptive Future Architecture"] end

P --> R1 P --> R2 R1 --> F R2 --> F ```

To combat bureaucratic inertia, Hopper instituted a strict rule against clinging to tradition: “I think the saddest phrase I ever hear in a computer installation is that horrible one 'but we've always done it that way.'” In her office, this phrase is forbidden. To prove that conventions are arbitrary, she hangs a clock that runs entirely counterclockwise. Visitors cannot read it on their first day; by day two, they realize ten-of is now ten-after; and by day three, they realize there was never any intrinsic reason a clock dial had to run clockwise. She also keeps a clock where a stationary pointer reads numbers rotating on a drum, a digital clock, and an hourglass given by her crew, all serving as reminders to challenge reflexive habits. She offers a humorous threat to the audience: anyone who says “we've always done it that way” in the next 12 months will find her materializing at their side to haunt them for 24 hours until they reconsider.

[25:33](https://www.youtube.com/watch?v=si9iqF5uTFk&t=1533s) Challenging the First "No" and Forgiveness over Permission

Addressing the EDP (Electronic Data Processing) Policy Committee of the Joint Chiefs of Staff—composed entirely of generals and admirals—Hopper reminded senior leadership of an uncomfortable reality: they are too buried under massive reports and administrative decisions to track overnight technical revolutions, meaning they must listen to their juniors. Her guiding advice to junior officers, enlisted personnel, and civilians alike is to “Never, never, never take the first no.” People in power frequently reject ideas on first contact out of sheer laziness—because agreeing forces them to act—or as an intentional test to see if the applicant believes enough in the concept to return.

Drawing on her World War II experience at the Bureau of Ordnance (BuOrd), Hopper recalls a supervisor who reflexively dismissed every opening suggestion. She outmaneuvered him by walking in and announcing, “Let's pretend this is the second time I'm presenting this,” exposing his reflexive pattern and allowing her to push critical work forward. She underscores that junior innovators must bypass bureaucratic roadblocks: “I long ago discovered that the best way to get something done was to do it—and if necessary, apologize.” When challenged, she jokes, she simply plays the role of a helpless old female to diffuse disciplinary pushback.

- Enlisted personnel and junior officers are often closer to the practical applications of technology than flag officers managing large organizations. - A supervisor's first "no" is typically an organizational filter rather than a definitive technical judgment. - Taking initiative and begging forgiveness afterward routinely achieves operational results where formal channels stall.

[27:35](https://www.youtube.com/watch?v=si9iqF5uTFk&t=1655s) Grassroots Microcomputer Innovation in the Navy

Hopper illustrates the power of junior initiative through several real-world naval examples. One junior lieutenant brought his own personal microcomputer aboard an administrative ship that the Navy deemed too small for computer resources; his administrative records and reports became so indispensable that when he transferred, the ship's captain bought the computer from him. In another case, a squadron commander ordered to deploy to an aircraft carrier faced leaving his maintenance logs behind at the Naval Air Rework Facility (NARF). Rather than fly blind, he purchased an Apple computer, enlisted an ensign and a Data Processing Technician (DP), copied all the maintenance files, packed the computer into the luggage compartment behind his cockpit seat, and flew out to the carrier.

The most transformative example occurred when an Electronics Technician First Class (ET1) in the Pacific Fleet built a microcomputer aboard his ship. After the *Navy Times* ran a photograph of the sailor and his machine, Admiral Collins mailed him a personal letter of congratulations outside normal military channels. The sailor responded in kind, sending a ten-page, single-spaced letter detailing the systemic failures of Pacific Fleet data processing and proposing technical fixes:

> “He then went on for 10 pages, both sides single spaced, and told the Admiral exactly what was wrong with the computers in the Pacific fleet and what ought to be done about it.”

Recognizing raw competence, the Admiral transferred the technician to Norfolk, assigned him three additional ETs, programmers, and a budget, and tasked them with assembling a custom machine. Within four months, using off-the-shelf components, they built a three-box microcomputer complete with a database management system.

```mermaid flowchart LR accTitle: Growth of the Micro Evaluation Group accDescr: Sequence showing how an enlisted technician's letter resulted in the Naval Regional Data Center Micro Evaluation Group.

subgraph Grassroots["Field Initiative"] A["ET1 Builds Custom Computer"] --> B["Navy Times Photo & Admiral's Letter"] B --> C["10-Page Single-Spaced Fleet Critique"] end

subgraph Development["Norfolk Unit"] C --> D["Transferred to Norfolk with Team & Budget"] D --> E["Off-the-Shelf System Built in 4 Months"] E --> F["Micro Evaluation Group Formed at NRDC"] end

subgraph FleetSupport["Fleet Services"] F --> G["Microcomputer Hardware/Software Testing"] F --> H["RFP & Acquisition Consulting for Bases"] F --> I["Naval Microcomputer Seminar"] end ```

The unit evolved into the Micro Evaluation Group under the Naval Regional Data Center (NARDAC) Norfolk, evaluating virtually every microcomputer and commercial software package on the market to assist naval stations with requests for proposals (RFPs). When they organized an open seminar on microcomputers, expecting 100 attendees, they had to cap attendance at 300. The enlisted sailors set up 27 vendor microcomputers, each demonstrating an active, functional Navy workload. The group's leader—now Chief Petty Officer Slater—subsequently authored a widely distributed manual titled *Everything You Ever Wanted to Know About Microcomputers, But Didn't Know Who to Ask*, setting the standard for microcomputer adoption across naval shore installations.

[32:42](https://www.youtube.com/watch?v=si9iqF5uTFk&t=1962s) Historical Perspective: From the Harvard Mark I Forward

Reflecting on why she is constantly pushed to think about the technological horizon, Hopper contrasts modern microcomputers with her first assignment on the Harvard Mark I in 1944. Housed in a glass case designed by industrial designer Norman Bel Geddes, the Mark I measured 51 feet long, 8 feet high, and 8 feet deep.

- Internal storage capacity was limited to 72 words of memory. - Each word was formatted as 23 decimal digits plus an algebraic operational sign. - Operational speed peaked at three additions per second, where the machine fetched two operands from memory, summed them, and stored the result back.

While such performance seems trivial by modern standards, Hopper stresses historical context: in 1944, the Mark I was heralded in newspapers and magazines as the most remarkable calculation tool humanity had ever devised, representing the dawn of automated digital computing.

[33:44](https://www.youtube.com/watch?v=si9iqF5uTFk&t=2024s) The Exponential Jump in Computing Speeds

Captain Grace Hopper traces the rapid acceleration of computing machinery from its wartime origins to the modern era. The very first machine designed to assist human brainpower rather than muscular strength operated at a pace of 333 milliseconds per addition—about three additions a second. Development accelerated under wartime contracts between the Department of Defense and universities, leading to the landmark introduction of the first commercial electronic computer in 1951: the UNIVAC I. Celebrating its 30th birthday just the prior year at the National Computer Conference with a full birthday cake, the UNIVAC I had reduced addition times to 282 microseconds, representing a thousandfold speedup over earlier machines.

The leap did not stop there. By 1964, Control Data Corporation released the CDC 6400, bringing addition times down to 300 nanoseconds—another factor of a thousand faster. Speculating as a self-described "nut about the future," Hopper projects the next line of progress: an eventual "XYZ system" capable of a full addition cycle (reading from storage to adder, computing, and returning the answer to storage) in a mere 300 picoseconds. She stresses that this next thousandfold jump is not an idle theoretical exercise, but an urgent practical necessity for real-world problems facing humanity.

- **First brain-assisting machine:** 333 milliseconds per addition (~3 additions per second). - **UNIVAC I (1951):** 282 microseconds per addition (1,000× speed increase). - **CDC 6400 (1964):** 300 nanoseconds per addition (another 1,000× speed increase). - **Future theoretical target:** 300 picoseconds (300 trillionths of a second) complete addition cycle.

```mermaid flowchart LR accTitle: Evolution of Computer Addition Speeds accDescr: Progression from early wartime computing through UNIVAC and CDC to proposed picosecond systems. subgraph Early["Early Eras"] M1["Early Machine 333 ms"] U1["UNIVAC I (1951) 282 µs"] end subgraph Later["Modern & Future"] C1["CDC 6400 (1964) 300 ns"] F1["XYZ System (Future) 300 ps"] end M1 -->|"1,000x faster"| U1 U1 -->|"1,000x faster"| C1 C1 -->|"1,000x faster"| F1 ```

---

[35:15](https://www.youtube.com/watch?v=si9iqF5uTFk&t=2115s) Global Weather Models and Satellite Image Processing

Hopper connects raw computing capacity directly to human survival, arguing that feeding an expanding global population requires drastically improved long-range weather forecasting. She cites a disaster in Iowa where farmers planted corn, only for unexpected heavy rains to wash out the seedlings; delays waiting for replacement seed and fertilizer pushed the replanting so late that an early autumn frost destroyed the crop. Had meteorologists been able to warn them in advance, the planting could have been delayed and the crop saved. Hopper observes:

> “Yeah, we do not today have a computer which will run a full-scale model of the big heat engine which consists of the atmosphere and the oceans.”

While historical meteorology lacked sufficient data—relying on the Navy dropping radio buoys in rivers and oceans or retrieving physical magnetic tapes installed on commercial flights upon landing—the modern problem is an embarrassment of riches. Modern Landsat satellite photography provides extraordinary detail, capable of discerning wave heights in the middle of the Pacific and water temperatures twenty feet beneath the ocean surface. However, the computational cost of exploiting these images is astronomical: fully enhancing a single Landsat satellite frame requires $10^{15}$ arithmetic operations. On the best available computers of 1982, processing one image takes nearly three days, rendering the analysis useless because “the weather's already happened.”

---

[37:06](https://www.youtube.com/watch?v=si9iqF5uTFk&t=2226s) The Looming Crisis of Water Resource Management

Beyond weather, Hopper identifies water resource allocation as an immense domestic challenge requiring unprecedented computational power. Across the country, regional fights over water access are already spilling into public life and the legal system. In northern New Jersey, strict rationing limited residents to fifty gallons per person per day, enforced through water meter inspections and aggressive fines. In Virginia, the city of Norfolk began running out of water and attempted to quietly drill wells on the corner of the naval base, only to be sued by neighboring Suffolk County for draining their groundwater.

The crisis spans the entire continent: excessive extraction in Florida has triggered devastating sinkholes swallowing houses and cars, while in Colorado, the dry eastern plains clash with the water-rich western slope over proposals to bore tunnels through the Rocky Mountains to divert supplies. Across Nevada, California, and Colorado, interstate lawsuits proliferate over river diversions and groundwater quotas. Hopper suggests that the United States might someday import water from Canada instead of oil, and challenges the audience to envision the immense computational overhead needed to coordinate fair, pure water distribution nationwide:

> “Can you imagine what kind of computer power it's going to take to manage water, so that every individual in the United States gets his fair share of pure water?”

---

[38:49](https://www.youtube.com/watch?v=si9iqF5uTFk&t=2329s) The Administrative Burden on Small Towns: The Need for "Itty-Bitty" Computers

Shifting focus from massive supercomputers to microcomputers, Hopper argues that "itty-bitty computers" are equally indispensable across society. She shares an anecdote about a small town in New Hampshire that formerly operated with a rudimentary septic system and a massive, open-air burning trash dump. When the Environmental Protection Agency (EPA) intervened, the town accepted federal grant money to construct a modern tertiary sewage treatment plant and a municipal incinerator, even celebrating the incinerator dedication with a proud New England marching band parade.

However, accepting federal money transformed the administrative burden on the local town clerk. Previously, her record-keeping consisted of just two simple handwritten lists: one to check off taxpayers who had paid, and another to check off attendees at town meetings. Suddenly, she was legally mandated to prepare distinct, complex reports for township, county, state, and federal bodies—including the EPA, OSHA, EEOC, IRS, and Social Security Administration. Each agency demanded numbers categorized and summed according to different schemas, leaving the clerk buried under paper without an automated desktop computer. Hopper emphasizes that this plight is not unique to New Hampshire:

> “And that's happening to every small business, every doctor, every lawyer, and every small town across the country.”

---

[40:04](https://www.youtube.com/watch?v=si9iqF5uTFk&t=2404s) Visualizing Time: Cut Off a Nanosecond

To illustrate why these scaling numbers baffle people, Hopper describes her own habits as an employee:

> “I normally drive all of my bosses totally nuts, because I won't do anything until I understand what I've been told to do.”

Early in her career, when managers spoke of additions taking milliseconds, she demanded to see what a thousandth of a second looked like, but no one could show her. Later, colleagues criticized her code, claiming, “Hey, you wasted 3—5 microseconds.” Lacking intuition for what a million of anything looked like—having never seen a check larger than a thousand dollars—she found microseconds equally incomprehensible.

The confusion peaked when engineers began measuring circuit operations in nanoseconds (billionths of a second). Frustrated by abstract explanations, Hopper called the engineering building and made an unconventional demand: “Please cut off a nanosecond and send it over to me.” She wanted a tangible piece of wire matching the maximum distance electricity can travel at the speed of light in a vacuum during one billionth of a second. The resulting visual aid measured exactly 11.8 inches long.

```mermaid flowchart TD accTitle: Physical Scale of Computational Time accDescr: Diagram illustrating Hopper's physical wire models for nanoseconds, microseconds, and picoseconds. A["1 Picosecond (1/1,000 ns)"] -->|"Ground pepper specks"| B["Grains on a table"] C["1 Nanosecond (1 billionth of a sec)"] -->|"Speed of light"| D["11.8 inches of wire"] E["1 Microsecond (1 millionth of a sec)"] -->|"Speed of light"| F["984-foot coil of wire"] ```

---

[42:40](https://www.youtube.com/watch?v=si9iqF5uTFk&t=2560s) Teaching Admirals, Airport Security, and Ground Pepper Picoseconds

Having established the nanosecond wire, Hopper subsequently requested a comparative microsecond wire: a massive coil measuring 984 feet. She advocates hanging a 984-foot coil over programmers' desks to remind them of the physical cost whenever they carelessly waste machine cycles. Bringing bundles of multi-colored nanosecond wires to her lectures, Hopper explains their extraordinary utility in executive briefings:

> “They're absolutely marvelous for explaining to wives and children and—admirals and generals.”

The wires provide an immediate physical explanation for why circuit components must sit close together inside a chassis, or why bouncing signals off communications satellites in geostationary orbit incurs unavoidable latency.

Carrying these teaching props, however, comes with logistical hazards. Hopper cautions her listeners that while she usually checks the wires in luggage, she once attempted to carry them through National Airport in her shoulder bag, resulting in a twenty-minute security interrogation explaining electrical propagation times to security personnel before being allowed to board. Returning to her proposed 300-picosecond machine, Hopper explains that because a picosecond is a thousandth of a nanosecond, wire cannot illustrate it: the best way to represent picoseconds is to grab a large pepper grinder and grind tiny specks all over the table.

[44:26](https://www.youtube.com/watch?v=si9iqF5uTFk&t=2666s) Hitting the Speed-of-Light Barrier and the Parable of the Two Oxen

Grace Hopper examines the physical constraints confronting computer hardware when aiming for extreme performance. When dealing with operations in the range of 300 picoseconds—roughly a third of a nanosecond—the physical distance required to fetch data, perform addition, and store the result exceeds the allowable signal path. Pushing computer clock cycles into picoseconds runs directly into the velocity of light. She remarks playfully on physics: Dr. Einstein established that as matter reaches the speed of light, it converts to energy. Hopper jokes that while brilliant young engineers might eventually reach into an "anti-universe" of white holes, quarks, and gluons, they certainly will not do so within the next five years, which is when she needs computing solutions.

```mermaid flowchart TD accTitle: The Oxen Parable for Computing Power accDescr: Diagram illustrating the flawed approach of building a bigger single machine versus the common-sense approach of adding multiple systems. subgraph Problem["The Physical Barrier"] A["Higher Processing Demands"] --> B["Shrinking Cycle Times: 300 picoseconds"] B --> C["Speed of Light Constraint"] end subgraph FlawedApproach["The Flawed Method"] C --> D["Build a Bigger Computer"] D --> E["Analogous to Growing a Bigger Ox"] end subgraph Solution["Common-Sense Architecture"] C --> F["Add Another Computer"] F --> G["Build Systems of Computers: Two Oxen"] end ```

To resolve the impasse, Hopper advises looking to history and applying common sense, which she laments seems to be the last thing people ever use when working with computers. Recalling the early history of America, pioneers moving heavy timber did not have Caterpillar tractors or heavy cranes; they used oxen. If a giant log was stuck on the ground and one ox could not move it, they did not try to breed a giant, gargantuan beast. They simply harnessed a second ox. The lesson applies squarely to computer architectures: rather than straining against physical laws to construct a single monolithic machine, one should combine multiple computers into a unified system. She emphasizes that common sense is a rigorous scientific method, citing the mathematician George Pólya from Princeton—author of the two-volume work on problem-solving techniques and the paperback *How to Solve It*—who devoted a whole chapter to the role of common sense in problem solving.

- “When we need greater computer power, the answer is not get a bigger computer — it’s get another computer.” — Capt. Grace Hopper - Light travels roughly one-third of a nanosecond in a very short distance, limiting how fast signals can travel back and forth across circuits at 300-picosecond cycle times. - Pólya's *How to Solve It* is highlighted as formal proof that common sense is a valid problem-solving framework in science and engineering.

---

[46:24](https://www.youtube.com/watch?v=si9iqF5uTFk&t=2784s) Systems of Computers and Three-Dimensional Flowcharts

Because building larger single processors hits physical limits, Hopper states that computing must shift to systems of computers. While critics often object that multicomputer systems are too expensive, plunging hardware costs have eliminated that objection. Even early 4-bit single-chip microcomputers, such as the Intel 8021—featuring 64 words of data storage and 1,000 words of program storage—could be bought for as little as 13 cents each in quantities of one hundred. With chips this cheap, nothing stands in the way of building distributed multi-computer configurations.

The true operational hurdle Hopper encountered was conceptual: visualizing and communicating how these distributed components interconnect. Conventional two-dimensional flowcharts drawn on flat paper fail to capture concurrent, networked architectures. To solve this, she initially layered transparent plastic plates to build three-dimensional flowcharts resembling a 3D chess set, using string and Scotch tape to link connections between layers, though the tape kept peeling off. She then turned to a Tinker Toy set, using its wooden wheels, blocks, and connector sticks to assemble physical models of computer flows. When she exhausted her supply of parts, she submitted an official Navy requisition for two large Tinker Toy sets—prompting a bemused visit two days later from her superior asking, "Well, Grace, what are we doing now?"

```mermaid flowchart LR accTitle: Molecular Model Mapping for Distributed Systems accDescr: Color-coded representation of system components modeled after chemistry ball-and-stick sets. subgraph Legend["Color-Coded Ball-and-Stick Model"] R["Red Balls: Computers"] B["Blue Balls: Databases"] Y["Yellow Balls: Database Managers"] G["Green Balls: Switches"] end R --- G G --- Y Y --- B ```

Hopper suggests a modern alternative for anyone planning multicomputer architectures: borrow the ball-and-stick modeling kits used by organic chemists to represent molecules. By assigning colors—such as red for computers, blue for databases, yellow for database managers, and green for communication switches—designers can construct physical three-dimensional models showing interconnections, data paths, and network topography. She urges the NSA audience to abandon flat sheets of paper when designing distributed architectures, warning them with a grin that while their bosses might demand explanations when chemistry sets show up on official purchase orders, a 3D physical model is the only effective way to understand and explain multi-computer systems.

- “They’ve got to be in three dimensions, and you’re going to have to explain to people what these systems of computers are doing, and I think the best solution is get one of those chemistry sets if you can.” — Capt. Grace Hopper - The Intel 8021 is cited as evidence of cheap commodity processing power, available for roughly 13 cents per unit in 100-unit batches. - Visualizing complex networked topologies requires physical 3D representations because 2D planar drawings cannot cleanly illustrate multifaceted communication links and database management paths.

## Notable quotes > [44:26](https://www.youtube.com/watch?v=si9iqF5uTFk&t=2666s) When we need greater computer power, the answer is not get a bigger computer — it’s get another computer. — Capt. Grace Hopper

> [25:33](https://www.youtube.com/watch?v=si9iqF5uTFk&t=1533s) I long ago discovered that the best way to get something done was to do it—and if necessary, apologize. — Grace Hopper

> [22:39](https://www.youtube.com/watch?v=si9iqF5uTFk&t=1359s) I think the saddest phrase I ever hear in a computer installation is that horrible one 'but we've always done it that way. — Grace Hopper

> [17:02](https://www.youtube.com/watch?v=si9iqF5uTFk&t=1022s) And yet the data is our raw material—our output is information, our product—and we should be concentrating on the data and the information. — Grace Hopper

> [08:43](https://www.youtube.com/watch?v=si9iqF5uTFk&t=523s) Nobody is looking at the value of information or comparative value of different pieces of information, and we’ve got to look at it because it’s cutting up our online systems. — Grace Hopper

## Mentioned Grace Hopper, Hyman Rickover, Henry Ford, Model T, U.S. Navy, U.S. Coast Guard, Tactical Air Command, Maxwell Air Force Base, Randleman, Privacy Act, Harvard Mark II, Naval Surface Warfare Center, American Federation of Information Processing Societies (AFIPS), Annals of the History of Computing, Naval War College, Joint Chiefs of Staff, Bureau of Ordnance (BuOrd), Apple, Collins, Slater, Naval Regional Data Center (NARDAC) Norfolk, Harvard Mark I, Norman Bel Geddes, UNIVAC I, Control Data Corporation, CDC 6400, Landsat, EPA, OSHA, EEOC, IRS, Social Security Administration, Albert Einstein, George Pólya, How to Solve It, Intel 8021, Tinker Toy

## Video description Part One of "Future Possibilities: Data, Hardware, Software, and People" presented by Capt. Grace Hopper at NSA in 1982.

[Source](https://www.youtube.com/watch?v=si9iqF5uTFk)

中文简报

光速极限阻碍芯片性能提升，霍珀呼吁采用多计算机系统物理光速极限阻碍了单处理器扩展突破皮秒级周期，使得廉价微型计算机分布式网络成为满足激增计算需求的唯一可行途径。格蕾丝·霍珀上校结合其自哈佛马克一号（Harvard Mark I）起数十年的海军计算经验发出警告：计算机行业过度关注硬件工具，而非数据的价值、流动与完整性，这可能重蹈交通运输业的覆辙。她认为，各类机构必须严格清理过期的在线记录，并正视不准确信息带来的重大法律责任。面对光速带来的物理限制，霍珀断言计算的未来不在于构建更大的单一处理器，而在于将廉价、分布式的微型计算机联网构建成系统。在整场演讲中，她大力提倡初级人员发挥主观能动性，敦促从业人员摒弃官僚惯性，运用常识来解决技术瓶颈。格蕾丝·霍珀警告称，计算机行业正重蹈交通运输业的系统性错误，过度关注孤立的硬件，而没有分析更广泛的信息流，也未能评估所处理数据的内在价值。 (5:56) 数据质量低下在《隐私权法》（Privacy Act）等联邦法规下伴随着重大的财务和法律责任；模型显示，在8,000份人事记录中若存在5%的错误率，可能会给相关机构带来约495,000美元的潜在赔偿责任。 (13:12) 计算速度的提升在皮秒级周期面临光速所施加的物理限制，因此必须采用分布式多计算机架构，而非构建越来越大的单一庞大处理器。 (44:26) 代表一光纳秒的11.8英寸导线以及分子球棍模型工具包等实体教学教具，是用于传达电路延迟和复杂三维分布式系统拓扑的关键工具。 (40:04)

Reading summary

Captain Grace Hopper argues that the computing industry must shift its primary focus away from isolated hardware mechanisms toward the economic value of information, data integrity, and distributed multi-computer architectures. Prioritizing Information Flow Over Hardware Tools (5:56) Hopper warns that the computer industry is repeating the historical mistakes of the transportation sector, which focused heavily on mass-producing automobiles while neglecting the rail infrastructure required to move freight, fuel, and military hardware. In computing, microcomputers represent a 'Model T' era, yet professionals remain fixated on hardware gadgets and software layers instead of analyzing organizational information flow. She stresses that computing machinery is merely tooling; raw data is the input and information is the finished product. Quantifying Data Value, Lifecycle Costs, and Liability (11:40) Organizations frequently hoard stale records online due to internal vanity rather than operational necessity, ignoring the economic intersection where the mounting cost of storing and maintaining records exceeds their operational value. Hopper notes that forward-looking military branches resolved performance bottlenecks by separating active operational profiles from older archival data, retaining recent entries online and moving historical records to batch storage. Failing to manage data accuracy also generates quantifiable financial liabilities under legal statutes like the Privacy Act. Hopper cites an investigation by Lieutenant Colonel Randleman at Maxwell Air Force Base, which modeled an 8,000-person personnel roster at an assumed 95% accuracy rate. Flawed records were estimated to trigger 360 adverse career decisions, resulting in approximately 180 civil lawsuits and roughly $495,000 in damages and legal fees. Hopper argues that calculating such liabilities is essential for organizations to justify the budget required to cleanse their data files. Challenging Bureaucratic Inertia Through Grassroots Initiative (22:39) System planning requires evaluating potential future conditions and calculating the cost of not acting, yet administrative habits often default to the defense of 'we've always done it that way.' To illustrate that conventions are arbitrary, Hopper keeps an operational counterclockwise clock in her office. She advises junior personnel never to accept an initial rejection from supervisors who may be testing their resolve or resisting extra effort, urging them to implement solutions independently and apologize afterward if challenged. Grassroots initiative frequently outpaces top-down planning during technological transitions. In the Navy, junior personnel bypassed procurement bottlenecks by bringing commercial microcomputers onto ships to run essential flight maintenance logs and administration. An enlisted technician’s detailed critique of Pacific Fleet computing led Admiral Collins to fund a specialized team in Norfolk that assembled a functioning microcomputer and database within four months, ultimately growing into the Micro Evaluation Group to test commercial systems and guide fleet-wide acquisition. The Speed-of-Light Barrier and Multicomputer Architecture (44:26) Demands for computing capacity continue to surge to address complex challenges such as continental water distribution and satellite meteorological models, where processing a single Landsat image requires 10^15 operations. However, attempting to scale single processors toward picosecond cycle times confronts physical limits dictated by the speed of light, which Hopper illustrates using an 11.8-inch wire representing the distance electricity travels in one nanosecond. Rather than attempting to build an impossibly fast single machine, Hopper proposes applying the frontier parable of the two oxen: when one animal cannot pull a log, teamsters add a second ox rather than breeding a larger one. Plummeting hardware costs make combining multiple microcomputers into distributed systems practical and cost-effective. Because conventional two-dimensional flowcharts cannot depict networked concurrency and data paths, Hopper advocates using physical, three-dimensional models, such as organic chemistry ball-and-stick sets, to map distributed multi-computer configurations. Hopper emphasizes that overcoming physical hardware constraints and administrative inertia requires treating common sense as a rigorous engineering discipline. While distributed architectures offer a viable path beyond single-processor limits, organizations remain constrained until they establish objective methods for measuring the operational value and financial risk of the data they process.

精炼阅读摘要

Grace Hopper 强调计算机行业必须摆脱对孤立硬件的狭隘崇拜，将核心转向信息流管理与数据本身的价值评估；在面对单机计算遭遇光速物理极限的挑战时，行业应转向分布式多计算机系统，并通过自下而上的主动创新打破体制惯性。数据价值评估与劣质数据的财务风险 (5:56) Hopper 指出，计算机专业人员往往盲目沉溺于处理机制与代码堆叠，却长期忽视数据本身的内在价值。她将硬件与软件界定为加工原料的工具，而信息才是最终产出。随着数据量非线性膨胀与即时在线访问需求的双重挤压，系统盲目保留所有历史记录会导致性能急剧退化。信息的运营价值通常在事件发生后迅速达到峰值并逐渐平缓，而维护与存储成本却随时间线性累积，终将出现成本超越价值的交叉点。为此，她提出评估信息价值的四项标准：采取行动的时间窗口、受影响的人数、涉及的资金体量，以及对管理层决策的关键度。例如美国海岸警卫队将浮标档案拆分为近期在线与长期批处理存储，显著提升了响应效率。在数据质量方面，业内普遍缺乏对劣质数据潜在损失的量化意识。Hopper 引用 Maxwell 空军基地 Randleman 中校依据《隐私法》构建的责任模型指出，如果一份包含 8,000 名人员的档案仅有 95% 的准确率，剩余 5% 的错误（400 条记录）就可能导致 360 起负面晋升或评定决策；若按 50% 的起诉概率及每案 2,750 美元的法定赔偿与诉讼费用计算，联邦机构将面临高达 49.5 万美元的败诉赔偿风险。这证明只有量化错误数据的潜在代价，管理层才能客观确立数据清洗与质量控制的预算合理性。光速物理极限与“两头牛”分布式架构 (44:26) 随着计算机主频向数百皮秒推进，硬件架构不可避免地撞上了光速这一物理壁垒。Hopper 解释称，在 300 皮秒的完整加法周期内，电信号在真空中的传播距离极其有限，单台机器内部的数据读取、运算与写回路径在物理尺度上无法无限缩短。针对如何进一步提升算力的争论，她借用美国拓荒时期的历史公理阐述其解决方案：当一头公牛无法拖动沉重的巨木时，拓荒者绝不会费尽心机去培育一头巨型牛，而是直接套上第二头牛。同理，当算力达到极限时，正确的技术路径是构建由多台计算机协同工作的系统，而非强行制造更大的单体超级计算机。随着单片微处理器成本大幅下探（如包含基础存储的 Intel 8021 芯片单价可降至约 13 美分），构建多计算机系统的经济阻碍已被消除，真正的难点转变为系统架构的可视化与理解。平面图纸无法表达并发与交错的网络拓扑结构，为此 Hopper 摒弃了传统的二维流程图，先尝试利用 Tinker Toy 木质积木搭建立体模型，随后提倡借用有机化学的分子球棍模型进行系统映射：以红色球代表计算机、蓝色球代表数据库、黄色球代表数据库管理器、绿色球代表通信交换机，从而直观展现多处理机架构中的复杂连接与交互逻辑。算力鸿沟：从全球资源调控到基层微机需求 (33:44) 从 1944 年 Harvard Mark I 每秒执行 3 次加法，到 1951 年 UNIVAC I 的 282 微秒，再到 1964 年 CDC 6400 的 300 纳秒，计算性能经历了量级跃迁，但 Hopper 强调未来对于 300 皮秒级系统的需求并非理论空谈，而是维系人类社会生存运转的迫切需要。全球长周期气象预报由于缺乏能完整模拟大气与海洋热力系统的计算能力，导致农业生产面临不可预测的灾害损失；一颗 Landsat 卫星单张图像的全面增强处理需要高达 10 的 15 次方次算术运算，在 1982 年的最佳计算机上耗时长达 3 天，使实时预警完全失效。同时，全美各地区在地下水超采、地层下陷及跨州河流分流上的尖锐冲突，同样亟需庞大算力来建立全国水资源调配模型。在超级算力之外，微型计算机在基层管理中同样不可或缺。Hopper 列举了新罕布什尔州一个小镇的遭遇：该镇在申请联邦资金升级污水与垃圾焚烧设施后，原本仅依靠两张手写清单的镇办事员瞬间被 EPA、OSHA、IRS 等各级监管部门的报表需求淹没，微机成为基层实体摆脱行政瘫痪的唯一工具。为了向各级决策者解释运算周期的物理现实，Hopper 随身携带 11.8 英寸长的导线作为一纳秒在光速下传播距离的实物模型，并用 984 英尺的导线卷象征一微秒，以此警示技术人员切勿在代码中挥霍宝贵的机器周期。反思制度惯性与自下而上的技术创新 (22:39) Hopper 强烈批判官僚体系内部“我们向来如此行事”的惰性思维，并在办公室悬挂逆时针运行的时钟与旋转式仪表，以证明技术习惯的约定俗成往往毫无客观必要。借鉴海军战争学院的推演原则，她主张任何重大规划都必须执行两项强制性审查：评估针对所有潜在未来事件与敌方行动的应变预案，以及全面核算“完全不执行该计划”所带来的沉没成本。而在当时的计算机规划中，机构往往只是机械地将现有业务投影到现成硬件上，缺乏对未来需求的前瞻设计。面对高层管理者的官僚阻力，Hopper 建议初级军官与技术人员“切勿接受第一个拒绝”，并践行“先行实施、必要时道歉”的行动准则。她列举了海军内部的数项草根突破：年轻军官自购微机登舰管理行政事务，最终迫使舰长出资采购；中队指挥官将 Apple 计算机塞入驾驶舱后备箱带上航空母舰，确保了飞机的维护数据不脱节；一名太平洋舰队的一等电子技术员自制微机后，越级致信 Collins 上将详细揭露舰队数据处理缺陷，促使军方将其调任 Norfolk 组建微机评估组（Micro Evaluation Group），最终牵头制定了全海军微机采办与技术转化的标准化规范。 Hopper 的演讲揭示了计算机工业从大型机时代向微机及分布式架构转型时期的结构性矛盾，主张通过客观量化信息生命周期成本来规避法律风险与资源浪费。然而，关于多机系统内部网络同步与通信延迟的具体技术解法，以及数据时间价值量化公式的普适性验证，报告并未提供详尽的实证工程框架，仍停留在原则倡导与经验总结层面。

Detailed notes — zh

## Background 该视频由美国国家安全局（National Security Agency, NSA）于2024年8月26日在YouTube平台公开发布。根据页面简介，内容为葛丽丝·霍珀准将（Capt. Grace Hopper）于1982年在NSA发表的题为《未来可能性：数据、硬件、软件与人员（第一部分）》的演讲历史录像。 ## TL;DR 霍珀结合自身在海军服役与参与早期计算机研发的非凡经历，警示计算机行业切莫重蹈当年忽视综合交通系统而单抓汽车的覆辙，强调必须先理清全局信息流与数据的真实时效价值，而非盲目堆砌硬件与将所有数据实时在线化。她通过生动案例抨击了官僚体制中“向来如此”的僵化思维，热情鼓励年轻官兵勇于尝试、先斩后奏，并以光速物理极限直观演示了微秒与纳秒的概念。面对海量气象与资源计算需求，她指出单机升级必然受制于物理瓶颈，倡导从“一头牛拉不动就套两头牛”的朴素常识出发，全面走向基于廉价微处理器的分布式多计算机系统与三维架构思维。 ## Atmosphere & style 整场演讲洋溢着一种兼具长者睿智与反叛幽默的独特气场，霍珀准将以轻松自嘲的军旅趣事与“飞蛾Bug”等历史掌故开篇，瞬间拉近了与NSA情报与技术受众的距离。她的台风干练犀利、妙语连珠，掏出11.8英寸电线道具展示“一纳秒”时充满童趣与启发性，而在痛批官僚惰性与思维定势时又字字珠玑、掷地有声。现场氛围既像是一堂大师级的技术战略前瞻课，又如同一位身经百战的老水兵在炉火旁传授“先做后道歉”的处事兵法，充满穿透时代的历史厚重感与行动号召力。 ## Bulletin - [03:07](https://www.youtube.com/watch?v=si9iqF5uTFk&t=187s) 格雷斯·霍珀指出计算系统设计正重蹈 20 世纪交通规划仅关注汽车而毁掉铁路的覆辙，强调必须先理顺组织内部的完整信息流，再决定硬件采购。 - [13:12](https://www.youtube.com/watch?v=si9iqF5uTFk&t=792s) 数据处理行业长期聚焦硬件与软件工具而忽视核心数据原料；事实上在麦克斯韦空军基地案例中，仅 5% 的人事档案错误率就因联邦《隐私法》带来近 50 万美元的潜在法律赔偿风险。 - [44:26](https://www.youtube.com/watch?v=si9iqF5uTFk&t=2666s) 单机运算周期逼近 300 皮秒时将遭遇不可逾越的光速物理极限，霍珀以“一头牛拉不动原木不该培育巨牛，而应套上两头牛”作比，力推多机协同与分布式网络架构。 - [46:25](https://www.youtube.com/watch?v=si9iqF5uTFk&t=2785s) 微处理器成本出现断崖式下跌，例如 Intel 8021 单片微型计算机采购单价降至 13 美分，彻底粉碎了构建多处理器协同系统成本过高的陈旧论调。 ## Key takeaways - [00:39](https://www.youtube.com/watch?v=si9iqF5uTFk&t=39s) 哈佛 Mark I 是全美第一台大规模数字计算机且二战期间完全由海军人员操作，每个计算记录都必须包含明确的“标识符”以便定位与检索。 - [03:07](https://www.youtube.com/watch?v=si9iqF5uTFk&t=187s) 亨利·福特的流水线与可互换零部件引发汽车普及，但缺乏全局统筹导致铁路系统破败；计算机系统设计若脱离整体信息流盲目堆砌硬件，必将重演这一悲剧。 - [06:25](https://www.youtube.com/watch?v=si9iqF5uTFk&t=385s) 评估信息价值需依据行动时效、影响生命、涉及金额与决策权重四大维度，而不能仅仅听从“叫得最响的高管”来制定系统调度优先级。 - [08:44](https://www.youtube.com/watch?v=si9iqF5uTFk&t=524s) 盲目将所有数据搬上在线系统多源于部门虚荣心，通过追踪访问计数并对冷热数据进行在线与批处理分级，可大幅削减系统开销并恢复性能。 - [11:40](https://www.youtube.com/watch?v=si9iqF5uTFk&t=700s) 信息随时间推移价值逐步趋平，而在线维护成本呈急剧上升趋势，系统架构设计必须找到成本超过价值的临界点并将陈旧数据下线归档。 - [17:02](https://www.youtube.com/watch?v=si9iqF5uTFk&t=1022s) 历史上第一个真实的计算机“Bug”源于 1945 年哈佛 Mark II 继电器中夹死的一只飞蛾，该日志现保存在海军水面武器中心博物馆。 - [22:39](https://www.youtube.com/watch?v=si9iqF5uTFk&t=1359s) 规划必须对照未来可能发生的所有事件以及“不执行计划的代价”展开审查，而计算机部门最危险的思维毒药就是“我们向来这么做”。 - [22:39](https://www.youtube.com/watch?v=si9iqF5uTFk&t=1359s) 办公室悬挂逆时针旋转的时钟有力证明所谓的客观物理铁律很多只是思维定势，霍珀以此警诫员工跳出习惯性思维框架。 - [25:38](https://www.youtube.com/watch?v=si9iqF5uTFk&t=1538s) 面对官僚机构习惯性的推诿与拒绝切勿轻言放弃，往往需要历经多次交涉，并践行“事后道歉比事先请示容易”的行动法则。 - [29:31](https://www.youtube.com/watch?v=si9iqF5uTFk&t=1771s) 海军基层年轻官兵自费携个人电脑登舰并组装系统，凭借市售商用元件（COTS）迅速解决复杂任务，管理高层必须重视年轻一代的技术洞察力。 - [33:44](https://www.youtube.com/watch?v=si9iqF5uTFk&t=2024s) 计算速度从 Mark I 的 333 毫秒跨越至 UNIVAC I 的 282 微秒再到 CDC 6400 的 300 纳秒，每一次飞跃都在推动人类向皮秒级算力迈进。 - [35:22](https://www.youtube.com/watch?v=si9iqF5uTFk&t=2122s) 全球人口增长带来的粮食与水资源调配压力需要前所未有的算力支持，完整增强一张卫星图像需要 10^15 次运算，当时最好的计算机处理需近 3 天。 - [40:07](https://www.youtube.com/watch?v=si9iqF5uTFk&t=2407s) 光在真空中的物理传播极限对应 1 纳秒为 11.8 英寸导线、1 微秒为 984 英尺线卷，直观教具揭示了硬件布局紧凑化与节约时钟周期的必要性。 - [44:26](https://www.youtube.com/watch?v=si9iqF5uTFk&t=2666s) 单机性能逼近光速极限时，突破算力瓶颈的正道是采用多计算机协同架构，正如拓荒时代增加牛的数量来搬运巨木。 - [47:00](https://www.youtube.com/watch?v=si9iqF5uTFk&t=2820s) 分布式多计算机架构打破了二维图纸的表达限制，霍珀倡导利用化学分子球棒模型将计算机、数据库、管理器与交换机以三维立体方式清晰呈现。 ## Detailed walkthrough ### [00:39](https://www.youtube.com/watch?v=si9iqF5uTFk&t=39s) 海军的第一台计算机与帽子上的“标识符” 葛丽丝·霍珀准将（Capt. Grace Hopper）以对现场介绍的回应作为演讲开篇。她幽默地解释了自己为什么喜欢这段开场白：因为这让她有机会提醒所有人，美国历史上第一台大规模数字计算机其实是一台美国海军的计算机（由哈佛大学与海军合作的 Harvard Mark I），在第二次世界大战期间完全由海军人员操作运行。她特别强调自己最近经常需要向公众反复重申这点，调侃道：“因为某个‘年轻的军种’（junior service，暗指美国空军）总想把这些早期计算机的功劳据为己有，而那时他们甚至都还不存在呢。” 紧接着，霍珀谈到了自己为什么在台上依然戴着海军制服军帽。她指出这顶帽子是她的“标识符”（identifier）。她借此向在场人员普及计算机基础：计算机系统中的每一条记录都必须包含一个标识符，这样系统才能知道把它存放在何处以及如何取回。然而，标识符在现实世界中经常引发误会，因为“生成记录的人”与“查看记录的人”对标识符的理解可能完全脱节。霍珀分享了几个令人捧腹的亲身经历： - 当她穿着海军常服戴着帽子穿梭在机场时，常有人走过来问她：“去休斯敦的下一班飞机几点起飞？”把她当成了地勤。 - 在旧金山，她在酒店电梯里遭遇了一次彻头彻尾的“降职”——走下电梯时，同乘的一位女士低声问丈夫那人是谁，丈夫一本正经地回答：“那是个保安。” - 霍珀前往加拿大圭尔夫大学（University of Guelph）演讲时，多伦多机场的海关入境官员看着护照和她，困惑地问：“你是什么人？”霍珀回答：“美国海军。”对方打量了她半天，脱口而出：“那你一定是他们那儿年纪最大的军官了。”霍珀打趣道这可不是欢迎访客的礼貌方式，而她当时唯一能想到的回击是反驳说“不，海曼·里科弗海军上将（Admiral Rickover）比我还大六岁”，可惜对方大概根本不知道里科弗是谁。讲完这些趣事后，霍珀摘下帽子露出一头白发，正式切入技术与时代演变的正题。 --- ### [03:07](https://www.youtube.com/watch?v=si9iqF5uTFk&t=187s) 福特 T 型车革命与交通系统规划的惨痛教训霍珀回忆起自己童年时的纽约市，当时沿哈德逊河的河滨大道（Riverside Drive）还是一条未经铺砌的泥土路。在周日下午，全家人会坐在路边观看漂亮的马车经过。整个下午偶尔只能看到一辆汽车，因为那时的汽车极其昂贵，完全手工打造，不仅没有加油站（远行需要携带五加仑汽油铁桶绑在后座），一旦在犹他州荒野发生机械故障，车主只能发电报给制造商，厂家派技工带着毛坯零件现场打磨组装。随后亨利·福特（Henry Ford）带着两大颠覆性概念登场：**标准可互换零部件（standard interchangeable parts）**与**流水线装配（assembly line）**，并推出了传奇的福特 T 型车（Model T）。霍珀指出人们如今已经遗忘了这一变革对世界的深刻重塑：车辆售价降至 300 到 600 美元，普通大众都买得起车；拥有汽车后，人们开始要求修建公路；路网铺开后催生了加油站、汽车修理厂；接着人们得以迁往郊区并开车通勤，进而推动了住宅周边大型购物中心的拔地而起。然而，霍珀敲响了警钟：今天计算机产业正处于微型计算机（microcomputer）带来的“T 型车时刻”，这是全美最大工业的开端。但当年人们在汽车发展中犯下的宏观错误正在重演： > “当我们修建了所有那些公路和购物中心，并为汽车交通提供了一切便利时，我们遗漏了某些东西——我们忘记了交通是一个整体，我们仅仅盯着汽车本身。” 由于缺乏整体统筹，当年被忽视的铁路系统今天彻底破败： - 铁轨路基年久失修。 - 由于民用车如今全靠公路平板卡车运输，国防上若想把主战坦克从内陆运往海港以备出海，甚至找不到足够的铁路平车（flat cars）。 - 若想用煤炭替代石油能源，铁路上连同时运输粮食作物与煤炭的漏斗车（hopper cars）都严重不足。霍珀严肃地总结道，整个社会在综合交通管理上交出了一份极其差劲的答卷。而在微型计算机时代，人们如果不吸取教训，依然会重蹈覆辙：盲目采购一堆孤立的硬件，再往上堆砌应用程序，而完全忽略了最核心的底层基础——**整个组织或企业内部完整的信息流（total flow of information）**。她极力主张，系统设计必须先全盘梳理信息流，再选用适宜的计算机硬件来支撑这一流动。 ```mermaid flowchart TD accTitle: 从信息流驱动系统设计 accDescr: 对比错误的孤立采购硬件模式与正确的信息流驱动架构设计模式 subgraph WrongWay ["常见的错误模式（重蹈公路交通覆辙）"] W1["盲目采购硬件设备 (Microcomputers)"] --> W2["堆砌单点应用程序"] W2 --> W3["整体架构脱节 / 类似铁路破败的系统危机"] end subgraph RightWay ["霍珀提倡的设计哲学"] R1["全盘梳理组织的信息流动 (Total Information Flow)"] --> R2["定义数据价值与访问时效"] R2 --> R3["选配针对性的计算硬件与在线/离线策略"] end ``` --- ### [06:25](https://www.youtube.com/watch?v=si9iqF5uTFk&t=385s) 信息的价值：被忽视的四大评估标准如果以信息流为核心来构建系统，首先必须解决的问题就是：我们处理的信息究竟价值几何？霍珀透露，近八年来她走访各地不断询问人们如何评估手头信息的价值，换来的却只有“有生以来见过的最精彩的茫然目光（blank stares）”。霍珀自嘲说，自己起初曾天真地以为，只要研究现有计算机系统的作业调度优先级（priorities），就能反推出信息的价值层级。然而这一尝试迅速碰壁，她发现： > “最高优先级永远属于叫得最响的高管（the senior squeaky wheel），而根本不是属于最具价值的信息。” 为了说明信息价值的客观差异，霍珀举了一个密歇根州完全由计算机自动化控制的化工厂案例。系统接收营销部门的指令，由计算机控制阀门、管道输送物料、记录库存产出、结算员工工资，并生成精美的报表呈送总裁案头。假设计算机系统同时从两个不同端口接收到两条数据流： 1. **端口 A**：来自车间阀门的报警信号，提示“若不立刻开启，整个化工厂即将爆炸”——处置时间不足 1 分钟，直接关系到 100 条人命和价值 1 亿美元的厂房设施。 2. **端口 B**：考勤数据，记录员工乔（Joe）昨天下班加了两个小时班。霍珀质问：哪一条信息更具价值？我们评估的标准又是什么？她由此总结出评估信息价值的四个潜在维度： - **行动时效（Time to act）**：系统在信息失效或产生灾难前可用的处置时间窗口。 - **涉及的人员生命（Lives affected）**：该信息影响到的人员生命安全规模。 - **涉及的财务金额（Dollars affected）**：信息直接关联的经济损失或价值大小。 - **决策重要性（Importance in decision making）**：该数据对组织全局决策所起到的支撑权重。霍珀大声疾呼，当时整个行业在“信息价值”领域几乎没有任何学术研究与论文发表，业界完全忽略了这一点。然而，未来的两大确定趋势已经形成不可调和的冲突：**数据总量正在以超线性（more than linear）的速度疯狂增长**，而**用户对数据即时访问（instant access）的需求也在急剧上升**。若不厘清信息的真实价值，系统的盲目扩张必将陷入瘫痪。 --- ### [08:44](https://www.youtube.com/watch?v=si9iqF5uTFk&t=524s) 盲目“在线化”的虚荣与冷热数据分级实践在信息价值模糊的背景下，计算机部门面临着严重的虚荣陷阱：几乎所有业务部门都叫嚣着要把自身的所有数据搬到“在线系统（online system）”中。霍珀直言，很多时候这纯粹是为了部门的“面子（prestige）”，而不是业务的刚需。为了拆穿这种虚荣，霍珀在一个机构搞了一次恶作剧式的测试：她在该部门数据库的每条记录上悄悄捆绑了一个计数器（counter），只要该记录被读取一次，计数器就自动加 1。六个月后，霍珀打印出了所有“访问次数为零”的记录清单。结果令人震惊：**其中一个完整的业务文件库在整整半年内从未被任何人查阅过一次**，而当初该数据的负责人曾极力坚持这批数据必须保持 24 小时实时在线。随后，霍珀列举了两个通过识别数据时效价值、对系统实施“瘦身”改造的成功范例： - **美国海岸警卫队（Coast Guard）的浮标档案改造**：海岸警卫队曾经对每一个航标浮标都建有详尽的历史档案。维护船出海检修浮标时，需要查阅该浮标过去几年的维护情况以及上次巡检留下的待办事项。然而这份档案始于早期的穿孔卡片，几十年下来记录被写得越来越冗长，庞大的在线历史包袱把整个检索系统拖得极慢。海岸警卫队重新审视了数据价值后决定进行切割：日常出海维护只需要最近两三年的巡检记录，这部分“前端数据”保留在线实时查询；至于该浮标几十年前何时采购、采购花费了多少资金等陈年旧账，只有在几年一次申请新预算时才会用到，隔天拿到报表完全不影响决策。于是，他们将久远的历史数据剥离并转回批处理（batch）离线保存，在线系统的性能瞬间恢复。 - **兰利基地战术空军司令部（Tactical Air Command at Langley）的人事档案优化**：该基地此前在为官兵分配基地勤务时，在线维护着每个人的生平完整档案，由于数据体量过大导致系统运行奇慢无比。重新评估后，管理者意识到：“我们在基地给一名士兵分配任务时，根本不需要他从高中至今的全部履历，我们只需要知道他最近上过的两所培训学校以及最近的两项任务派驻记录。”司令部随即实施了数据截断：将最近的即时历史保存在线，其余详尽履历打回离线批处理；如果该军人面临提拔、授奖或审计，相关背景调查等上一到两天出结果也完全来得及。霍珀指出，这两个案例表明部分前沿单位已经开始意识到信息的**时间价值（time value）**。但从整个工业界来看，依然没有任何人在严肃研究不同信息之间的相对价值与比价机制。如果系统设计者继续任由低价值历史数据塞满在线系统，未来的计算机架构设计必将陷入死胡同。在切入下一阶段的技术曲线前，霍珀强调，我们必须学会科学地为信息定价与定级。 ### [11:40](https://www.youtube.com/watch?v=si9iqF5uTFk&t=700s) 信息的价值与成本曲线：寻找下线临界点 Grace Hopper 探讨了信息随时间推移的价值与维护成本变化规律。在一个事件刚发生时，关于该事件的信息价值会瞬间急剧飙升，但随着时间推移，该信息的价值会逐渐趋于平缓。最终，这些信息要么被更新的数据所取代，要么因不再需要保持联机（online）状态而被转存至微缩胶片等历史归档介质中；即便在工业界，企业也必须为了应对国税局（IRS）的审计而保留记录。因此，信息价值曲线的典型形态是：迅速上升、走向平缓，最终转入某种形式的历史归档。与之相对的是信息的维护成本曲线。在事件发生之初，信息的获取与存储成本极低；但随着时间流逝，系统为了存储、维护以及向其追加新数据，所累积的成本会持续攀升，导致成本曲线呈急剧上升趋势。这两条曲线之间必然存在一个交汇点——在这一交汇点之后，继续在联机系统中维护该信息的开销就已经超过了其本身的价值。然而 Hopper 指出，当今的计算机领域根本不知道这个交汇点具体落在何处，因而无法合理地将陈旧数据移出联机系统，这需要对相关信息的价值与成本展开深入研究。正如 Grace Hopper 所强调的： > “Now there's a lovely crossover point there — that's the point at which keeping that information in our online system is costing us more than it's worth to us.” ```mermaid flowchart LR accTitle: 信息生命周期中的价值与成本变化 accDescr: 展示事件发生后信息价值先升后平，而维护成本持续上升并在交叉点后超过价值的过程。 subgraph Phase1["事件初期"] A["事件发生"] --> B["价值急剧飙升\n维护成本极低"] end subgraph Phase2["联机运行期"] B --> C["价值趋于平缓\n维护成本持续累积"] C --> D{"成本与价值交叉点\n(Crossover Point)"} end subgraph Phase3["归档处置"] D -->|"成本超过价值"| E["移出联机系统\n转入微缩胶片/历史档案"] end ``` --- ### [13:12](https://www.youtube.com/watch?v=si9iqF5uTFk&t=792s) 错误信息的潜在代价：以麦克斯韦空军基地的人事档案为例行业不仅缺乏对信息价值的评估，甚至从不计算系统中存在“错误信息”所带来的潜在代价。Hopper 分享了位于麦克斯韦空军基地（Maxwell Air Force Base）的兰德曼中校（Lieutenant Colonel Randleman）的研究。兰德曼关注到美国联邦《隐私法》（Privacy Act）中的一项严厉条款：如果人事档案中存在错误信息，且导致某人被剥夺晋升或加薪等权益，受害人有权直接起诉联邦政府。Hopper 逐字宣读了法案中对机构记录所要求的四个严苛标准——“准确性、关联性、时效性与完整性”（accuracy, relevance, timeliness, and completeness），并指出这是极少数赋予个人直接起诉联邦政府权利的法律条文之一。为了量化错误信息的经济风险，兰德曼中校做了一组严密的推演假设： - 假设一份涉及 8,000 名员工的人事档案准确率高达 95%（Hopper 调侃称全美根本找不出准确率达 95% 的人事档案）。 - 5% 的错误率意味着有 400 份记录含有错误信息。 - 兰德曼咨询了决策者与心理学专家，对方指出在当前没人愿意为他人担风险的环境下，错误信息在档案中极为扎眼，预计 90% 的情况下会导致不利决定，即 360 人遭遇负面人事决定。 - 按照概率论中的 50-50 估算，其中会有 180 人选择提起诉讼。由于档案错误确凿，政府必输无疑。 - 假设每起案件赔偿金为 2,000 美元（Hopper 认为这被严重低估），加上 100 美元法庭诉讼费及 650 美元律师费，单起案件政府损失为 2,750 美元。 - 180 起案件总计将带来高达 495,000 美元的潜在经济损失（接近 50 万美元）。 Hopper 总结道，唯有算出这一潜在损失，管理者才能具备清晰的经济依据去决定愿意花多少预算来清洗和校正数据。这也暴露了计算机行业过去三十年来的重大盲区：大家将所有精力放在了硬件与软件这类“处理工具”上，却完全忽略了作为生产原料的数据与作为最终产品的信息。Grace Hopper 严肃指出： > “We've talked about data processing for thirty years, we spend all our time talking about the processing hardware and software, we paid no attention to the data — and yet the data is our raw material.” --- ### [17:02](https://www.youtube.com/watch?v=si9iqF5uTFk&t=1022s) 第一个计算机“Bug”与二战时期的飞蛾为了阐明技术演进中的真实历程，Hopper 讲述了历史上第一个真实“Bug”（飞蛾）的诞生趣事。二战期间，团队在哈佛大学建造 Mark II 计算机。1945 年夏天剑桥极其炎热，由于战争时期物资紧张，他们只能在一栋一战时期遗留的临时建筑内办公，室内通风散热不良，窗户甚至没有安装纱窗。某天 Mark II 突然停机，团队逐一排查故障，终于在一个大型信号继电器中找到了故障根源——里面夹着一只被继电器触点活活夹死的大飞蛾。操作员找来镊子，小心翼翼地将飞蛾夹了出来，贴在当天的值班运行日志（logbook）上，并用透明胶带固定，在下方写道：“发现的第一个真实的 Bug”（First actual bug found）。这本贴有原始飞蛾的日志如今保存在弗吉尼亚州达尔格伦（Dahlgren）的海军水面武器中心博物馆内。Hopper 提到，过去很多人以为这只是个编造的段子，美国信息处理学会联合会（AFIPS）甚至特地组织了一支考察队前往达尔格伦核实，最终亲眼见到了胶带下的飞蛾，并拍下照片刊登在 1981 年 7 月号的《计算机历史年鉴》（*Annals of the History of Computing*）上。Hopper 幽默地打趣道： > “And I think it's rather nice that the Navy is keeping a few of the early artifacts like the first bug and me and a few other things.” --- ### [19:28](https://www.youtube.com/watch?v=si9iqF5uTFk&t=1168s) 战后转编受阻与海军战争学院的非常规解题法 1946 年二战结束，海军允许战时女性预备役人员（WAVES）申请转入常规现役海军。Hopper 递交了转正申请，却因年龄被拒之门外——当时规定的最高年龄上限为 38 岁，而她当时已满 40 岁。Hopper 笑着向台下建议，在 40 岁时被人直截了当地告知“你太老了”其实是一桩好事，经历过这种心理创伤之后，余生便再也不会被年龄问题所困扰。转编被拒后，Hopper 选择继续留在海军预备役。当时的预备役人员必须完成三项任务：夏季集训、每周例会以及完成与军职代码对应的函授课程。Hopper 当时的专业代号是军械军官（Ordnance Officer，后来人事部门又把她错改成了航空工程师）。在学完所有关于大口径舰炮与炮塔的军械教材后，为了凑满晋升学分，战战兢兢的 Hopper 只好选修了海军战争学院（Naval War College）的高级课程。战争学院给出的第一道大题要求在“最短时间内完成一支特混舰队的海上燃油补给”，题目仅给出了各型舰艇的抽油与受油速率： - Hopper 起初对海上补给一无所知，只能先让一艘补给油船给航空母舰加油，但显然达不到“时间最短”的要求。 - 随后她注意到各舰的流速差异，发现可以一边从油船向航母输油，一边同时由航母向驱逐舰输油。 - 以前学过的“问题求解课”曾教导她“任何解法都必须进行拓展”，于是她又把输油管线从驱逐舰继续延伸接给了一艘护卫舰。 - 课程还教导她“解法必须进行普遍化推广”，于是她在油船的另一侧并联挂载了巡洋舰、驱逐舰和护卫舰，最终画出了一幅大半支特混舰队全用管线串联在一起、在茫茫大洋中央浩浩荡荡并排航行的壮观图景。 - 战争学院批改后退回了这份作业，只留下了一句意味深长的评语：“极具趣味的解法。” 紧接着的下一道考题要求在最短时间内调度一个潜艇中队在加勒比海完成侦察搜寻。对潜艇同样外行的 Hopper 决定向她的计算机求助，为每艘潜艇编写了一套“随机游走”（random walk）程序，生成了一张在极短时间内完全覆盖海域的复杂航迹图。正如 Hopper 回顾这段经历时所说： > “Now, somewhere along the line, somebody had given me a course in problem-solving and they told me to always extend every solution.” ### [22:39](https://www.youtube.com/watch?v=si9iqF5uTFk&t=1359s) 军事学院的规划教训与“我们向来这么做” 格雷斯·霍珀（Grace Hopper）回忆起当年在海军战争学院（Naval War College）做规划推演的经历。前两个潜艇调度方案堪称光怪陆离：她设计的潜艇航线在海图上互相交叉、原地掉头，甚至还有一艘在上方兜了个小圈子才折返。她笑称自己当时甚至开始同情那位不得不批阅这些奇葩方案的战争学院教官。然而，第三个演练才是真正的关键所在——她接到的任务是制定一份夺取岛屿的作战计划。方案完成后，教官要求她必须进行两项复盘与审查：第一，对照敌方所有可能的行动以及未来可能发生的所有事件来审查该计划；第二，认真评估“若不执行该计划所必须付出的代价”。霍珀强调，这两项审查对于任何规划都至关重要，但令人痛心的是，在当今计算机领域的规划中，人们却屡屡将它们抛诸脑后。霍珀指出，计算机界存在一种极其恶劣的倾向：“我们往往完全根据单位现有的设备和目前正在做的事情来制定计算机规划，却全然没有对照未来可用的新技术设备以及未来将要承担的新任务来加以审视。”而在计算机机房或机构里，最令人沮丧的一句话莫过于“可是我们向来都是这么做的”（but we've always done it that way）。在她的办公室里，这句话被列为绝对禁语。为了彻底打破这种思维惯性，霍珀在办公室挂了一面完全逆时针运转的时钟。第一天来访的人往往完全看不懂时间；到了第二天，他们才发现原本的“差十分”变成了“过十分”，便能重新读懂表盘；通常要等到第三天，大家才会恍然大悟：世上根本没有任何客观物理定律规定指针必须顺时针旋转，逆时针转完全可行，甚至指针固定而刻度盘在圆柱鼓轮上旋转也同样能精确走时。霍珀以此告诫所有人，许多所谓的“铁律”不过是毫无根据的习惯。机场的行李传送带之所以顺时针运转尚有合理解释——因为多数人是右撇子，顺着运转更容易提包；但直升机旋翼的转向为何如此规定，连她也没弄清缘由。霍珀郑重向在场所有人宣布，她要赠送大家一份无形的“礼物”并许下一个诺言：“在接下来的十二个月里，如果你们当中有任何人胆敢说出‘可是我们向来都是这么做的’，我就会立刻化作幽灵出现在你身旁，纠缠你整整二十四小时，直到你重新开动脑筋思考为止。”她幽默地补充道，这招绝对管用，因为她已经收到了七十多封感谢信，感谢她以这种方式“显灵”点醒了陷入僵化思维的人。 - 战争学院两项核心审查：对照未来可能发生的敌情与事件审查计划、审查“不执行计划”的沉重代价。 - 计算机规划通病：受限于现有设备和眼前业务，缺乏面向未来技术和未来任务的前瞻性评估。 - 办公室的逆时针时钟：用以打破认知盲区，证明习惯不等于真理。 - 禁忌语：“可是我们向来都是这么做的”被霍珀视为计算机部门最具破坏力的一句话。 --- ### [25:38](https://www.youtube.com/watch?v=si9iqF5uTFk&t=1538s) 永远不要接受第一次拒绝：跨越层级推动创新霍珀指出，推进新技术面临的最大障碍就是“改变人的观念极度困难”。她曾向参谋长联席会议（Joint Chiefs of Staff）的电子数据处理（EDP）政策委员会做汇报，台下坐满了资深将军与海军上将。霍珀在会上当面提醒这群将领：他们每天案头都堆满了厚重的研报需要批阅消化，背负着极其重大的决策责任，客观上根本没有充裕的时间去跟上几乎是一夜之间发生剧烈变革的信息技术；因此，这群身居高位的长官必须学会俯下身倾听年轻部下的意见。霍珀对军队和机构中的年轻一代——无论是军官、士兵还是文职人员——给出了最核心的行事忠告：“永远、永远、永远不要接受第一次拒绝。” 霍珀将那些惯于说“不”的人分为两类：第一类人纯粹是因为懒惰，在政界、商界和工业界比比皆是，因为一旦他们批准了新想法，自己就必须跟进落实、承担工作；而第二类人则更加危险，他们每次听到新建议时本能地先说“不”，纯粹是为了测试你的信念——看看你是否对自己的想法有足够的信心，敢不敢再次登门据理力争。霍珀总结道：“因此，绝不要把第一次拒绝当回事，务必回去再试一次；事实上，我通常会承受大约四次拒绝，然后再琢磨如何绕过对方把事办成。” 这一套炉火纯青的处事手腕是霍珀历经沧桑磨练出来的。二战期间她在海军军械局（BuOrd）任职时就遭遇过这样一位上级。在接连提出两三次建议都被对方习惯性一口回绝后，霍珀摸透了他的套路。下一次再去汇报新构想时，她开门见山地说：“长官，咱们就假装这是我第二次向您提这个方案吧。”对方当场愣住，神情错愕。从此以后，霍珀彻底掌握了主动权，甚至可以在进门时直截了当地说：“长官，这是我第四次提出这项申请了，咱们干脆现在就同意了吧。” ```mermaid flowchart TD accTitle: 面对官僚拒绝时的应对策略 accDescr: 展示霍珀总结的如何应对官僚机构说“不”并最终促成创新的思维路径 A["提出新构想 / 新技术建议"] --> B{"对方初次回应"} B -->|"习惯性说‘不’"| C{"背后的真实心理"} C -->|"偷懒推诿 (怕承担后续工作)"| D["坚持再次递交申请"] C -->|"测试决心 (看你是否足够坚信)"| D D --> E{"经历多次沟通 (约4次拒绝)"| E E -->|"心理战术施压 (如直言‘假装这是第4次’)"| F["打破僵局获得批准"] E -->|"正面受阻"| G["灵活绕开障碍自行落实"] G --> H["用既成事实说话 (先做后道歉)"] ``` --- ### [27:35](https://www.youtube.com/watch?v=si9iqF5uTFk&t=1655s) 自带计算机与“事后道歉比事先请示容易” 霍珀列举了海军基层年轻官兵利用新技术解决现实问题的生动范例。有一名海军中尉（Lieutenant Junior Grade）被派往一艘小型舰艇任职，当时海军高层认定该舰吨位太小，根本没有必要配备计算机。但这名中尉负责行政管理工作，为了摆脱繁重低效的文书泥潭，他自掏腰包把自己的个人计算机带上了舰。不久之后，他把整艘军舰的所有档案和数据全部录入进电脑，各项汇报报表不仅出具得准时无比，而且数据极其漂亮、精确无误。等到这位中尉任期届满调离时，舰长为了维持高效运转，不得不自掏军费将他的那台计算机买了下来。另一个案例发生在一位海军飞行中队长身上。该中队接到调令要开赴航空母舰执勤，但按当时的死板规矩，中队战机的所有维修保养档案都必须留存在后方的海军航空兵翻修厂（NARF）。中队长对此极为不满，他坚信战机开到哪里，维护记录就必须跟到哪里。于是，他自费购置了一台 Apple 计算机，并在一名少尉和一名数据处理兵（DP）的协助下，“连借带偷、巧取豪夺”般地把翻修厂里的飞机档案全盘复制录入进这台 Apple 电脑。中队长给电脑配了一个手提箱，塞进座舱后方原本用来放随身行李箱的狭小空间里，直接驾机飞向航母。此后，全中队的飞机维护记录不仅随舰随行，还能随时在电脑上实时更新。当有人问这位中队长“按规定你准许这么干吗”时，中队长的回答干脆利落：“我根本没问过许可。”霍珀对此大加赞赏，并总结出了她名垂计算机与管理史的黄金法则：“在很久以前我就发现，把事情做成的最佳方式就是直接放手去做，事后如有必要再去道歉。”她笑着对听众说：“去道歉可比事先请示容易多了。”霍珀打趣道，每当惹出麻烦需要开脱时，她随时可以摇身一变，装成全天下“最无辜、最无助的老太太”蒙混过关。她以此力劝全军将领，必须放手让年轻人去拥抱新技术，不要被陈规陋习束缚手脚。 - 舰艇中尉案例：因舰小未配电脑，自费携机登舰处理全舰档案，调离时舰长被迫出资买下电脑。 - 飞行中队长案例：拒绝将维修记录留置后方翻修厂（NARF），自购 Apple 计算机拷贝数据装入座舱行李舱带上航母。 - 霍珀行动法则：“向来是直接放手去做更为容易，事后道歉也远比事前申请许可轻松得多。” --- ### [29:31](https://www.youtube.com/watch?v=si9iqF5uTFk&t=1771s) 水兵直言、微型机评估组与 Norfolk 研讨会在太平洋舰队，一名年轻的一级电子技术员（ET1）自己动手组装了一台计算机。当时负责公关报道的军官觉得很有看点，便拍了一张这位水兵与他自制电脑的照片登在《Navy Times》上。时任海军高级将领柯林斯上将（Admiral Collins）在报上看到了报道，亲自提笔写了一封祝贺信，并且跳过了所有繁琐的官僚层级渠道，通过直邮直接寄到了水兵手里。这名水兵拿到信后心想：既然上将能够跨级直接写信给我，那我也完全可以直接回信给上将。水兵随后给上将寄去了一份长达十页、双面单倍行距手打的长信。信中先是感谢上将的来信，调侃自己以前还不知道海军上将也会读《Navy Times》，随后便毫不留情、切中要害地罗列了太平洋舰队现有计算机系统存在的所有严重缺陷，并条分缕析地提出了改进方案。霍珀评价这封信是他们所见过的“最顶尖的海军系统调查报告”。上将读完大为震撼，当即动用人事权力，直接把这位水兵从太平洋舰队抽调至诺福克（Norfolk）。上将给他配齐了三名电子技术员（ET）、几名数据处理程序员（DP）以及专项经费，命令他们放手开发新型计算机。在短短四个月内，这群年轻人完全利用市售现成商用元件（COTS）打造出了一套包含三个小机箱、集成了数据库管理系统（DBMS）的高性能微型计算机系统。军方以此为契机，在诺福克海军区域数据中心（Naval Regional Data Center, NARDAC）旗下正式成立了“微型机评估组”（Micro Evaluation Group）。这群年轻人测试了全美市面上的几乎每一款微型机硬件并运行了绝大多数软件，对各项技术指标与实战适用性了如指掌。海军任何部门若计划采购微型机，都可以直接咨询他们以撰写需求书（RFP）或选型。几个月前，这群年轻士兵在诺福克举办了一场微型计算机研讨会，原先只敢奢望来 100 人，结果报名瞬间突破 300 人不得不紧急截止。他们说服了全美约 27 家微机制造商参展，每台设备现场运行的全部是真实的海军实际业务场景。该团队的斯莱特（Slater，现已晋升士官长 Chief）还撰写了一份权威报告——《关于微型计算机你想知道的一切，但不知该向谁请教》（Everything you ever wanted to know about microcomputers, but didn't know who to ask），成为全海军各基地及个人选购微机时争相索阅的“顶级指南”。霍珀感叹，高层领导平日全在忙于行政管理，唯有这些聪颖敏锐的青年军官与士兵才真正吃透了技术，海军必须认真倾听他们的声音。 --- ### [32:42](https://www.youtube.com/watch?v=si9iqF5uTFk&t=1962s) 初识 Mark I：计算机技术飞速演进的起点霍珀坦言，除了来自基层的技术冲击，还有一种源自技术演进历史的内在力量一直在驱使她着眼未来。她将视线拉回到三十八年前——1944 年，当她在哈佛大学第一次见到由霍华德·艾肯（Howard Aiken）领衔建造的马克一号（Mark I）自动序列受控计算机时的震撼场景。马克一号长达 51 英尺（约 15.5 米），高 8 英尺（约 2.4 米），纵深 8 英尺。整台庞然大物被安置在由著名工业设计师诺曼·贝尔·盖茨（Norman Bel Geddes）亲手设计的雄伟玻璃外壳之中。这台耗资巨大的机器在当时拥有令人惊叹的规格：它一共具备整整 72 个字的存储容量（words of storage），每个存储字由 23 位十进制数字加上一个代数正负符号组成。在运算速度方面，马克一号每秒钟能够执行整整三次加法运算——也就是每秒三次从存储器中调出两个数值、将它们相加，再把结果送回存储器保存。霍珀看着台下被这一微不足道的数据逗乐的 NSA 听众说道：在计算机性能已达天文数字的 1982 年，每秒三次加法和 72 个字的内存听起来简直寒酸可怜得令人发笑；然而，如果翻开当年的报纸和杂志，就会发现当时的社会舆论无一不将马克一号誉为人造机械史上最不可思议的奇迹工具，因为它是人类历史上第一台真正能按程序自动运转的通用数字计算机器。正是这种从极其原始的机械继电器到超大规模集成电路的巨大跨越，让她深信技术的演变绝不会停滞，更不能用过去的标尺衡量未来的可能。 - 马克一号尺寸：长 51 英尺、高 8 英尺、深 8 英尺，外包诺曼·贝尔·盖茨设计的巨型玻璃机箱。 - 存储与算力指标：容量仅 72 个字（每字为 23 位十进制数加正负号），运算速率为每秒 3 次加法。 - 历史对比反差：当年的工程奇迹在数十年后看似微不足道，印证了计算机技术呈指数级演进的必然规律。 ### [33:44](https://www.youtube.com/watch?v=si9iqF5uTFk&t=2024s) 算力演进史：从毫秒到皮秒的飞跃格蕾丝·霍珀（Grace Hopper）回顾了早期计算硬件的跨越式发展。作为人类历史上第一台“辅助人脑而非手臂力量”的计算机（Mark I），它完成一次加法运算需要 333 毫秒（即每秒执行 3 次加法）。在二战剩余的时间里，许多大学在国防部的资助下建造了更多计算机；直到 1951 年，第一台商用电子计算机 UNIVAC I 诞生。就在前一年的全国计算机大会（National Computer Conference）上，人们甚至为这位“老姑娘”庆祝了 30 岁生日，并为她准备了生日蛋糕。UNIVAC I 执行一次加法仅需 282 微秒，速度瞬间提升了近一千倍。技术演进的脚步并未停歇。到了 1964 年，CDC 6400 面世，其加法运算时间缩短到了 300 纳秒（即十亿分之三百秒），速度再次实现了千倍的飞跃。霍珀幽默地表示，如果你像她一样对未来极度痴迷，自然会忍不住推导序列的下一行：在未来的某个年份，人类是否会需要一套执行完整加法操作（从存储器到加法器取数、相加、再存回存储器）仅需 300 皮秒（即万亿分之三百秒）的系统？霍珀断言，现实中已经有关键领域急需这种速度。 ```mermaid flowchart LR accTitle: 计算机算力跨代演进 accDescr: 展示从Mark I到UNIVAC I、CDC 6400直至皮秒级系统的加法速度演进过程 subgraph Evolution["计算速度提升历程"] M1["Mark I (1944) 333 毫秒"] U1["UNIVAC I (1951) 282 微秒"] CDC["CDC 6400 (1964) 300 纳秒"] XYZ["未来系统 (? 年) 300 皮秒"] M1 -->|"提速约 1,000 倍"| U1 U1 -->|"提速约 1,000 倍"| CDC CDC -->|"需要再提速 1,000 倍"| XYZ end ``` - Mark I 执行单次加法耗时 333 毫秒（千分之 333 秒），每秒可完成 3 次加法。 - UNIVAC I 单次加法耗时 282 微秒（百万分之 282 秒），速度提高 1,000 倍。 - CDC 6400 运算速度达 300 纳秒（十亿分之 300 秒），速度再次提升 1,000 倍。 - 霍珀强调了对算力极限的紧迫需求：“Answer is we need it right now for a couple of problems, so what you needed very badly -- The population of the world is increasing.”（答案是，针对一些棘手问题，我们眼下就非常迫切地需要它——世界人口正在激增。） --- ### [35:22](https://www.youtube.com/watch?v=si9iqF5uTFk&t=2122s) 极端天气预报与海量卫星数据处理难题霍珀指出，随着全球人口的增长，增加粮食供应势在必行，而最能推动粮食增产的手段就是更精准的长期天气预报。她举例道，几年前爱荷华州的农民刚种下玉米，根还没扎稳，一场突如其来的暴雨就将幼苗冲刷殆尽；农户不得不等待第二批种子和化肥重新播种，却因周期延误遭遇早霜侵袭。如果当时能提前掌握暴雨信息并推迟播种，这批庄稼本可保住。然而，当今世界上没有任何一台计算机能够完整运行涵盖大气层与海洋的“大型热机”全尺寸模型，许多模型甚至从未经过实际测试。早年间，制约预测的是数据不足——海军只能在江河湖海中投放带无线电的浮标，或者在民航客机上加装传感器磁带并在降落后拆卸取样。如今虽然有了陆地卫星（Landsat）提供的高清影像，甚至能分辨太平洋中央的波浪高度及海平面下 20 英尺的水温，但处理这些图像面临着致命的算力瓶颈。 - 完整增强处理一张卫星影像需要执行 $10^{15}$ 次（一千万亿次）算术运算。 - 即便使用现存性能最顶尖的计算机，处理单张照片也需要耗费将近 3 天时间。 - “...to fully enhance a satellite photograph takes 10 to the 15th power arithmetic operations -- that s close to 3 days and our best computers and the weather s already happened.”（霍珀指出现实的尴尬：等顶级计算机耗费近三天终于算完时，天气事件早就已经发生了。） --- ### [36:50](https://www.youtube.com/watch?v=si9iqF5uTFk&t=2210s) 全美水资源争夺战与微型计算的行政需求霍珀指出的第二个急需算力的重大问题是全美的水资源管理。在美国各地，水源匮乏与冲突层出不穷：新泽西州北部曾规定每人每天限水 50 加仑，抄表员逐户检查并对超量者罚款；弗吉尼亚州诺福克市（Norfolk）打井取水，由于水井钻在了海军基地的角落，跨界到了萨福克县（Suffolk），引发萨福克县以盗窃地下水为由起诉诺福克县；佛罗里达州过度抽取地下水引发巨大天坑，吞噬了汽车与房屋；而在科罗拉多州，干燥的东半部试图打通落基山脉隧道去引西半部的水，遭到西半部的强烈抵制，整个西部的多个州都在为地下水和跨州河流的取水权打官司。未来美国甚至可能被迫从加拿大进口淡水而非石油，而实现公平分配水资源将依赖前所未有的算力。与此同时，微观层面的“超微型计算机”（itty-bitty computers）需求同样迫在眉睫。新罕布什尔州的一个传统小镇原本只有化粪池和露天焚烧垃圾场，后来环境保护署（EPA）拨付巨款，要求小镇建设三级污水处理厂和现代焚化炉。小镇居民为此兴高采烈地组织了带军乐队的盛大游行庆祝落成，但随即陷入文书地狱：掌管全镇记录的老太太原本只需要两张手写清单——一张用于纳税勾销，另一张用于镇民大会登记签到；但如今她必须向镇、县、州、联邦政府以及 EPA、OSHA、EEOC、IRS、社会保障局等无数机构报送报表。由于各机构的报表格式和统计口径各不相同，她不得不配一台专用电脑来专门应付政府报告。 - 水资源法律纠纷广泛蔓延于科罗拉多州、内华达州、加利福尼亚州等西部各州。 - “Can you imagine what kind of computer power it s going to take to manage water, so that every individual in the United States gets his fair share of pure water?”（霍珀感叹道，要确保每个美国公民都获得合理的洁净水配额，所需要消耗的计算能力将无法想象。） - 基层行政文书压力使得小诊所、小律师事务所乃至全国各个微型城镇都需要配备微型电脑。 --- ### [40:07](https://www.youtube.com/watch?v=si9iqF5uTFk&t=2407s) 一根 11.8 英寸的电线：纳秒与微秒的直观教学在探讨如何实现更高速的算力时，霍珀讲述了自己作为一个“让上司抓狂的麻烦员工”的故事——她坚持只有弄懂任务本质才会行动，因此总是不停追问。早期计算机在毫秒级运行时，上级告诉她毫秒是千分之一秒，她就要求工程师把毫秒“拿给她看”，却无人能做到。后来有人在审查程序时指责她“浪费了 3 到 5 微秒”，当得知微秒是百万分之一秒时，她依然无法想象，因为她这辈子见过的最大支票也没超过一千美元，根本无法具象化“百万分之一”。后来工程部门开始讨论纳秒（十亿分之一秒），对于缺乏“十亿”概念的华盛顿官僚和普通人而言，十亿分之一更是天方夜谭。霍珀在走投无路之下打电话给工程部：“请剪下一纳秒送过来给我。”基于光速计算，光在太空中十亿分之一秒内行进的最远物理极限距离正好是 11.8 英寸（约 30 厘米）。霍珀拿着用电线剪裁的“一纳秒”端详了整整一周，随后又要求工程师制作代表微秒的长度——足足 984 英尺（约 300 米）长的电线。 ```mermaid flowchart TD accTitle: 光速时间距离对应示意图 accDescr: 展示光速在纳秒、微秒和皮秒时间内所对应的物理传播极限距离 subgraph TimeDistance["光速极限与物理尺度对应关系"] PS["1 皮秒 (Picosecond) 胡椒粒大小粉末"] NS["1 纳秒 (Nanosecond) 11.8 英寸电线 (约 30 cm)"] US["1 微秒 (Microsecond) 984 英尺线缆 (约 300 m)"] US -->|"缩小 1,000 倍"| NS NS -->|"缩小 1,000 倍"| PS end ``` 霍珀幽默地分享了她随身携带这些物理“时间度量线”的经历。这些直观的道具在向将军、海军上将、妻子和孩子们解释技术概念时极其管用：无论是解释两台设备为何必须靠拢摆放，还是解释通过卫星发送电报为何需要耗费那么多“纳秒”。霍珀还讲述了一次安检趣事：平时她都会把这些电线放进托运行李中，有一次她随手装入单肩包去华盛顿国家机场赶飞机，结果在安检口足足花了 20 分钟向安检员科普什么是纳秒和微秒才获准登机。至于前面提到的 300 皮秒系统，霍珀笑着揭秘：皮秒是纳秒的千分之一，“制造皮秒最好的方法就是拿一个巨大的胡椒研磨器，把胡椒粉末研磨得满桌都是，那就是皮秒了。” - 1 纳秒在光速下的物理极值等同于 11.8 英寸长的导线。 - 1 微秒对应长达 984 英尺的线卷，霍珀主张将其挂在程序员桌前以示警醒。 - “I sometimes think we ought to hang on over every programmer s desk, so they ll know exactly what they re throwing away when they throw away a microsecond.”（霍珀说，她有时真想在每个程序员的办公桌上方都挂一卷 984 英尺长的微秒线，让他们明白挥霍一个微秒到底是在扔掉多大的一件东西。） ### [44:26](https://www.youtube.com/watch?v=si9iqF5uTFk&t=2666s) 光速极限与“两头牛”的启发格雷斯·霍珀（Grace Hopper）指出，当运算周期缩短至 300 皮秒（即三分之一纳秒）时，硬件设计将遭遇无法逾越的物理壁垒：电信号在极短距离内根本来不及完成两数相加并将结果存回，硬件已经逼近了光速极限。她幽默地援引爱因斯坦的理论调侃道，根据相对论，物质一旦达到光速就会转化为能量瞬间化为乌有（“poof”）；即便未来的年轻工程师们或许真能突破光速、进入充斥着白洞和奇异微观粒子（夸克与胶子）的反宇宙，那也绝不可能在未来五年内实现，而她现在就急需更强大的计算机。面对这一困局，最应当调动的其实是常识，然而在计算机领域，常识往往是人们最不愿采用的手段。既然常识被束之高阁，霍珀建议从建国初期的历史中汲取智慧。当年拓荒者在没有卡特彼勒（Caterpillar）拖拉机和大型起重机的情况下搬运巨木，当一头牛拉不动沉重的原木时，人们绝不会费尽心机去培养一头体型更庞大的巨牛，而是套上两头牛并力拉拽。霍珀借此直指现代计算的核心出路：“当我们需要更强大的计算机算力时，解决之道不是去造一台更大的计算机——而是再加一台计算机。”（“When we need greater computer power, the answer is not get a bigger computer -- it s get another computer.”）常识本身就是严谨的科学方法，普林斯顿大学数学家乔治·波利亚（George Pólya）在经典著作《怎样解题》（*How to Solve It*）中，就曾专门用一整章论证常识在问题求解中的核心价值。 ```mermaid flowchart TD accTitle: 单机性能瓶颈与多机协同方案对比 accDescr: 对比传统制造更大计算机的物理极限困境与采用多计算机协同系统的历史启发逻辑 subgraph Trap["传统思路：盲目追求单机巨型化"] A["提高单机主频 / 缩短周期至 300 皮秒"] --> B["面临光速物理极限"] B --> C["单机堆砌成本与物理不可行性"] end subgraph Solution["历史智慧与常识：系统化架构"] D["一头牛拉不动巨木"] --> E["不培育更大的牛，而是增加一头牛"] E --> F["构建多计算机协同系统"] end Trap -.->|"转变思维"| Solution ``` ### [46:25](https://www.youtube.com/watch?v=si9iqF5uTFk&t=2785s) 廉价芯片与多计算机系统的必然性要实现更庞大的算力，唯一的路径是构建计算机系统（即分布式与多处理器架构）。面对人们下意识提出的“成本过于高昂”的质疑，霍珀用当时微电子技术的发展数据进行了驳斥。随着半导体集成工艺的飞跃，硬件成本已出现结构性暴跌：即便像英特尔早期的 8021 单片微型计算机（配备 64 个数据字存储空间与 1000 个程序字存储空间），批量采购 100 片时的单价已经降至区区 13 美分。硬件造价不再是系统化扩展的绊脚石，没有任何理由能阻碍多机协同系统的建立。真正的障碍往往不在技术和成本本身，而在于人们固守单体机架构的惯性思维，没有及时认识到超低成本微处理器所带来的网络化架构契机。 - **英特尔 8021 单片机**：4 位单芯片计算机，内置 64 字数据存储与 1000 字程序存储空间。 - **采购成本断崖式下跌**：百片批量采购单价低至 13 美分，彻底粉碎了多计算机架构“造价过高”的陈旧论调。 ### [47:00](https://www.youtube.com/watch?v=si9iqF5uTFk&t=2820s) 从儿童玩具到三维分子架构模型一旦转向多计算机协同系统，传统的平面二维系统图便彻底失效。霍珀分享了自己探索三维流程图的曲折趣事：她最初尝试用透明塑料板分层绘制流程图，像搭立体国际象棋那样层叠起来，再用细绳和透明胶带在各层板之间拉线连结逻辑关系，但胶带极易脱落；随后她想到了儿童拼插积木 Tinkertoy，利用里面的圆盘、方块和木棒成功搭建起了立体逻辑架构。然而组件很快告罄，当她一本正经地向后勤部门提交申购两套大型 Tinkertoy 玩具的采购单时，两天后上司便神色复杂地找上门来质问：“好吧，格雷斯，我们这又是在折腾什么呢？”（“Well, Grace, what are we doing now?”）为了避免引发此类行政尴尬，霍珀向 NSA 的技术人员推荐了一个更具说服力的工具：化学研究中用于演示分子结构的多色球棒模型。她详细规划了如何将化学模型映射为系统级网络架构，并坚信系统设计必须跳出二维图纸的束缚： | 构件颜色 | 对应系统组件类别 | 职能说明 | |:--- |:--- |:--- | | **红球 (Red)** | 计算机单元 (Computers) | 承担实际运算与业务处理的计算节点 | | **蓝球 (Blue)** | 数据库 (Databases) | 底层数据持久化与信息存储节点 | | **黄球 (Yellow)** | 数据库管理器 (Database Managers) | 负责数据交互控制与调度的管理单元 | | **绿球 (Green)** | 交换机 / 路由设备 (Switches) | 负责节点间互联互通的网络交换结构 | 通过用连杆将不同颜色的球体串联，设计者能够一目了然地向决策者展示庞大计算机系统的拓扑走向与通信脉络。霍珀最后打趣提醒道，尽管采购化学模型套装同样需要向管理层解释理由，但至少比起在军方采购单上填写儿童积木玩具，这能免去许多平白无故的盘问与麻烦。 ## Notable quotes > [44:26](https://www.youtube.com/watch?v=si9iqF5uTFk&t=2666s) When we need greater computer power, the answer is not get a bigger computer -- it s get another computer. — Grace Hopper > [13:12](https://www.youtube.com/watch?v=si9iqF5uTFk&t=792s) We've talked about data processing for thirty years, we spend all our time talking about the processing hardware and software, we paid no attention to the data — and yet the data is our raw material. — Grace Hopper > [03:07](https://www.youtube.com/watch?v=si9iqF5uTFk&t=187s) 当我们修建了所有那些公路和购物中心，并为汽车交通提供了一切便利时，我们遗漏了某些东西——我们忘记了交通是一个整体，我们仅仅盯着汽车本身。 — Grace Hopper > [22:39](https://www.youtube.com/watch?v=si9iqF5uTFk&t=1359s) 我们往往完全根据单位现有的设备和目前正在做的事情来制定计算机规划，却全然没有对照未来可用的新技术设备以及未来将要承担的新任务来加以审视。 — Grace Hopper ## Mentioned Grace Hopper, Howard Aiken, Norman Bel Geddes, Hyman Rickover, Henry Ford, Lieutenant Colonel Randleman, Admiral Collins, George Pólya, Harvard Mark I, Mark II, UNIVAC I, CDC 6400, Intel 8021, Apple, Model T, Landsat, Tinkertoy, Caterpillar, United States Navy, United States Air Force, National Security Agency, United States Coast Guard, Tactical Air Command at Langley, Naval War College, Joint Chiefs of Staff, Bureau of Ordnance, Naval Regional Data Center (NARDAC), Environmental Protection Agency (EPA), Occupational Safety and Health Administration (OSHA), Equal Employment Opportunity Commission (EEOC), Internal Revenue Service (IRS), Social Security Administration, AFIPS, Navy Times, Annals of the History of Computing, Privacy Act, How to Solve It ## Video description Part One of "Future Possibilities: Data, Hardware, Software, and People" presented by Capt. Grace Hopper at NSA in 1982. [Source](https://www.youtube.com/watch?v=si9iqF5uTFk)

Source quotes

[44:26] Grace Hopper: When we need greater computer power, the answer is not get a bigger computer -- it s get another computer. [13:12] Grace Hopper: We've talked about data processing for thirty years, we spend all our time talking about the processing hardware and software, we paid no attention to the data — and yet the data is our raw material. [3:07] Grace Hopper: 当我们修建了所有那些公路和购物中心，并为汽车交通提供了一切便利时，我们遗漏了某些东西——我们忘记了交通是一个整体，我们仅仅盯着汽车本身。 [22:39] Grace Hopper: 我们往往完全根据单位现有的设备和目前正在做的事情来制定计算机规划，却全然没有对照未来可用的新技术设备以及未来将要承担的新任务来加以审视。

Source quotes

[44:26] Capt. Grace Hopper: When we need greater computer power, the answer is not get a bigger computer — it’s get another computer. [25:33] Grace Hopper: I long ago discovered that the best way to get something done was to do it—and if necessary, apologize. [22:39] Grace Hopper: I think the saddest phrase I ever hear in a computer installation is that horrible one 'but we've always done it that way. [17:02] Grace Hopper: And yet the data is our raw material—our output is information, our product—and we should be concentrating on the data and the information. [8:43] Grace Hopper: Nobody is looking at the value of information or comparative value of different pieces of information, and we’ve got to look at it because it’s cutting up our online systems.

Original transcript

[0:39] And there is a reason why I like that introduction. It s because it gives me [0:44] an opportunity to remind you that the first large scale digital computer in the United States was [0:50] a Navy computer, operated by Navy crew during World War Two. And recently I ve been finding [0:58] that I have to remind people that, because it s been a tendency on the part of a certain junior [1:04] service to try and claim credit for those early computers. And they didn t even exist [1:10] And they didn t even exist yet -- So -- [1:16] Please remember that it was a Navy computer -- And if you re wondering why I kept my cap on, [1:22] I had a reason for that too, [1:24] it s because this is my identifier -- I hope you all know by now that every [1:29] record in a computer system must have an identifier. That s so you [1:33] know where to put it and how to get it again. -- There s something odd about those identifiers, [1:39] though; they have to be understood both by the person that originally puts it on the record and [1:44] the person who later looks at the record -- [TIME: 00:01:46] [1:47] That s why my problem has been -- I go wandering around airports and [1:51] people come up to me and say, "When s the next plane leave for Houston?" [2:00] I got totally demoted one night and print San Francisco. I got off an elevator and [2:07] there was a couple in the elevator with me -- As I got off, I heard the woman said her husband. [2:12] "What was that?" -- You have heard the worst of it, and he [2:15] said "that was a security guard" -- So -- [2:21] Then I went up to Canada to speak at the University of Guelph and I had to go through [2:25] immigration at the Toronto airport. So I handed my passport to [2:29] the immigration officer and ...an officer and he looked at [2:31] it and looked at me and said, "What are you?" And I said, "United States Navy." [2:36] He took a second real hard look at me and then he said you must be the oldest one they ve got. [2:43] You know, um, I didn t really feel that was a polite way to welcome visitors to Canada. [2:51] [TIME: 00:02:50] But the only put me down I could think of was [2:53] to say no, Admiral Rickover is six years older. And I don t think he even knew who [2:58] Admiral Rickover was. But if you know what... [3:00] But if you know what I am I ll take my cap off. That only goes to show my white hair. [3:07] Actually, I can remember when Riverside Drive in New York City along the Hudson River was a [3:13] dirt road. And on Sunday afternoons, as a family, we would go out and sit on the [3:18] drive and watch all the beautiful horses and carriages go by. In a whole afternoon, [3:24] there might be one car; cars were enormously expensive. They were individually built -- [3:31] There was no such thing as gas stations if you went on a long trip you ve got five gallon cans [3:35] of gasoline, put them on the back deck, strap them the car and took your gasoline with you. [3:40] If you broke down in the middle of Utah, you wired back to the manufacture, and then he sent [3:44] a man out with a part and he worked on the part til it fitted your car. [3:49] And along came a gentleman named Henry Ford with two concepts: [3:53] standard interchangeable parts and an assembly line, and he started to build Model Ts. [3:59] [TIME: 00:03:59] I think we ve totally forgotten how [4:02] tremendously that changed the world -- You could have any color you [4:06] wanted as long as it was black -- They cost between three hundred and six hundred [4:12] dollars and people started to own cars -- Naturally, had once they had cars, [4:17] they demanded roads, we built them. Gas stations appeared, garages were stocked [4:22] with interchangeable parts, they appeared -- People found they could move [4:26] to suburbs and drive to work -- And then of course they wanted to shop near home, [4:31] so we had to build shopping centers -- I think we ve forgotten the tremendous [4:35] developments that followed from the Model T Ford -- [4:40] Now, whether you recognize it or not -- The Model Ts of the computer industry [4:48] are here. We ve been through the preliminaries of the industry -- [4:53] We re now at the beginning of what will be the largest industry in the United States, [4:58] and I m quite worried about something. When we built all those roads and the shopping centers [5:05] and all the other things, and provided for automobile transportation, transportation, [5:12] we forgot something. We forgot transportation as a whole. We only looked at the automobiles. [5:19] Because of that, today, when we need them again, the road beds, the railroads are falling apart -- [5:24] [TIME: 00:05:23] A dumping polygon [5:25] clear right around the countryside -- If we wanted to move our tanks from [5:29] the center of the country to the ports to shipped them overseas, [5:32] there are no flat cars left because we move all the cars on those racks on the roads now. [5:38] If we wanted to move coal to replace oil, they re, probably not enough hopper cars [5:42] to move both the grain crop and the coal -- And the truth of the matter is we ve done a lousy [5:47] job of managing transportation as a whole. -- Now, as we come to the world of the micro [5:56] computer, I think we [5:58] re going to be facing the same possibility. I m afraid we will continue to buy pieces of [6:03] hardware and then put programs on them, when what we should be doing is looking at the underlying [6:09] thing, which is the total flow of information -- -- to any organization, activity, company, [6:15] or what have you. We should be looking at the information flow, and then selecting the computers [6:21] to implement that information flow. [TIME: 00:06:24] [6:25] Now, of course, if we do that, one of the first things we ll need to know is something about [6:28] the value of the information we re processing. It s close to 8 years now that I ve been trying [6:33] to ask people how they value their information -- I ve gotten the finest assortment of blank stares [6:39] you ever saw in your entire life -- I even question whether there was a [6:44] difference. Naively, I thought I could find out how people were evaluating their information if [6:49] I could find out how priorities were assigned on the computer systems. Boy, did that go flat fast! [6:55] I found out exactly how the priorities are assigned. Top priority already goes to the [7:00] senior squeaky wheel, not to the most valuable information. Some people even questioned [7:06] that there was a difference in the value of information. I use as an example chemical plant -- [7:12] I know up in Michigan that s totally operated by computer. Information comes in from Marketing, [7:17] goes through the computer; it opens valves, pushes stuff through pipes, tells Inventory what [7:22] it s made; the people are paid by the computer; nice computerized reports go up to the president [7:27] s desk. Now, let s suppose that two pieces of information under that flow simultaneously from [7:32] two different ports in the system. One comes from a valve out in the plant and says, "If you don t [7:37] open me, the plant s going to blow up -- [TIME: 00:07:39] [7:40] You have less than a minute in which to act; a hundred lives at stake, hundred million dollar [7:44] chemical plant. At the same instant, in another part of the system, comes the fact that Joe did [7:49] 2 hours of overtime. Which is the more valuable piece of information? And what are our criteria? [7:56] I ve mentioned three possible criteria. The time in which we have to act; the number of lives [8:01] affected; the number of dollars affected. I think there s a fourth: the importance of that piece of [8:06] information in making decisions. No work -- no research has been done on [8:11] the value of information. We ve completely failed to look at it [8:16] and yet it s going to make a tremendous difference in how we run our computer systems of the future. [8:22] Cause there are two things that are dead sure; I don t even have to call them predictions. One [8:26] is that the amount of data and the amount of information will continue to increase, [8:30] and it s more than linear. And the other is the demand for instant access to that information [8:35] will increase. And those two are in conflict. We ve got to know something about the value of [8:41] the information being processed -- [TIME: 00:08:43] [8:44] Everybody wants our information online. If one department gets an online system than all [8:48] the other departments want an online system. In many cases, that s a matter of prestige, [8:53] not of actual need, and I played a very mean trick on one activity. I tacked counter on every record. [9:00] Every time the record was looked at I added one -- At the end of six months, I printed out everything [9:05] which had not been looked at -- One entire file fell out, [9:11] yet the owner of that data had insisted that his information must be online. [9:16] It was a matter of prestige to have his information online, [9:20] not that he really needed it there. One outfit has taken a second, a second [9:24] look at the data from that point of view -- it s the Coast Guard. [9:29] They had a file which contained the complete history of every buoy. And when [9:33] a ship went out to maintain the buoys -- They d look in the file to see what had [9:37] been done about the buoy over the last couple of years and whether [9:40] any message have been left to look at something next time. [9:44] [TIME: 00:09:43] Those records started years ago, [9:46] as a punch card and they d gotten longer and longer and longer and longer over the years. [9:51] The whole system was slowing down, and yet they needed rapid access to it. [9:55] So take a second look at those records, and they said, hey, [9:58] we don t need that whole record on line. All we want online, is the last couple of years. [10:04] We don t need to know when we bought the buoy and how much it cost unless we re going in for [10:07] a budget to get a new buoy. We can have that answer tomorrow or the next day. They chopped [10:14] those records. The front end of it that they need for reference to go out and maintain [10:17] the buoy is online. The rest of the record is going back to batch and you can have the answer [10:23] tomorrow or the next day. Somewhat the same thing has been done by Tactical Air Command at Langley. [10:29] They were carrying online, for assignment on base, the complete record and history of every person -- [10:35] The whole system was slowing down because the records were so long. [10:38] So the took a second look at the records and they said hey we don t need that whole record when we [10:43] re assigning a men on base. All we need to know is the last couple of schools he s been to and the [10:48] last couple of assignments he s had. [TIME: 00:10:50] [10:50] We don t care where he went to high school -- So they trap the records, the immediate past [10:55] history is online, the rest of it s going back to batch and if he s coming up for an [10:59] award or promotion or something you can have that tomorrow or the next day, [11:03] they ve begun to look at least at the time value of the information. There s [11:09] been no research in this area, there s no one publishing papers, not even on the relative [11:15] value of information within an organization -- Nobody is looking at the value of information [11:22] or comparative value of different pieces of information, and we ve got to look at it because [11:28] it s cutting up our online systems -- And we ve got to know more about the [11:32] value of information in order to design the systems of the future. [11:36] I thought up a couple of curves. I have no numbers to put on them and [11:40] research hasn t been done yet -- But at least I think I can [11:43] talk about the shape of them. Suppose this is dollars, and this is time -- [11:50] [TIME: 00:11:49] And an event occurs here. Now the [11:52] value of the information about that event goes up quite sharply immediately after the event, which [11:57] the further you get away from the event in time, the more the value of that information levels [12:02] off. It goes up very sharply and it levels off. Now ultimately, it either gets replaced by a new [12:09] piece of information, or we decide we don t need it online anymore and we transfer to historical [12:15] files, microfilm or something like that. Of course, in industry they have to save it [12:19] for the IRS, so the value curve probably look something like that: a sharp rise, [12:24] a leveling off, and then an eventual transfer to some form of historical file. [12:29] What about the cost of that information? Cost of information is very, very low at [12:34] the time of the event, but the further you get away from the event in time, [12:38] the more the cost you pile up to start, maintain it, and add any information to it. So the cost [12:43] curve starts low and then it goes zooming up -- Now there s a lovely crossover point there -- that [12:50] s the point at which keeping that information in our online system is costing us more than it [12:55] s worth to us. But because we don t know where that point is, we have no way of getting stuff [13:00] out of our online systems, and that depends on knowing something of the value and the cost of [13:06] the information concerned. We ve got a big job to do in investigating those areas -- [13:13] [TIME: 00:13:12] As a matter of fact, [13:14] we don t even know the possible cost of having incorrect information in a system. This vastly [13:22] upset Lieutenant Colonel Randleman down at Maxwell Air Force Base and he decided to investigate the [13:28] possible cost of having incorrect information in the system. He found a section in the privacy [13:33] law. Fortunately most of our government employees don t know it s there or haven t found it yet -- [13:41] which says that if you have incorrect information in a personnel file, and if because of it, [13:47] someone s denied a promotion or a raise or something like that, they have a right [13:52] to sue the federal government. It s one of the very few cases in which the individual [13:56] is directly given the right to sue the federal government and it s a very powerful paragraph. [14:02] Whenever any agency fails to maintain any record concerning any individual with such accuracy, [14:08] relevance, timeliness, and completeness -- boy, that s four powerful words! -- as is [14:14] necessary to assure fairness in any determination relating to the qualifications, character, rights, [14:21] opportunities of, or benefits to the individual that may be made on the basis of such record, [14:27] and consequently a determination is made which is adverse to the individual -- [14:31] [TIME: 00:14:30] the individual may bring a civil action [14:33] against the agency, and the District Courts of the United States shall have jurisdiction in the [14:37] matters under the provisions of this sub-section. So we decided to find out how much it might cost [14:43] to have incorrect information in a personnel file. And he said, let s suppose I have a personnel [14:49] file on 8,000 people. And he said further, let s suppose that I know the file is 95% correct -- He [14:56] s selected things and looked at em and gotten a -- correctness percentage. Of course, I don t believe [15:01] there s personnel file in the country that s 95% correct, but he said, let s suppose it is, [15:07] and that means that 5% of those records contain incorrect information. Four hundred of em contain [15:14] incorrect information. Then he went and talked to the decision making people, and the psychologists, [15:20] and so on, and he said, what s going to be the effect of that incorrect information? And [15:25] they said, well, it s going to stick out; it probably won t match the rest of the file -- [15:30] Nobody takes any chances on anybody nowadays; we think in 90% of those cases, a negative decision [15:37] will be taken on the basis of the incorrect information. That would mean in 360 cases, [15:43] a negative decision is taken on the basis of incorrect information. Then he said, [15:49] we don t know how many of those people will sue; we have no experience with that yet. So [15:53] by the laws of probability we ll have to say it s 50-50. 180 up and sue the government -- [15:59] [TIME: 00:15:59] Now, of course, they re bound win their suit, [16:01] because the incorrect information s in the file -- So he said, let s suppose the damages [16:07] are two thousand dollars -- I think he under estimated that, [16:11] hundred dollars for court cost six hundred and fifty for lawyers each in those cases is [16:15] going to cost us two thousand seven hundred and fifty dollars out of much do we stand [16:20] to lose because of incorrect information -- Well, it turns out that 180 times 2750 s darn [16:27] close to half a million dollars: $495,000, the possible cost of information in that personnel [16:35] file. Now until we make that computation of the possible cost of incorrect information, [16:41] we can t make a clear estimate of how much we are willing to [16:44] spend to correct the file -- I now know the economically: [16:47] I can go up to almost half a million dollars to get that file to a higher level of correctness, [16:52] because that s what I stand to lose -- We ve almost never made any computation of the [16:59] possible costs of incorrect information in the system. [17:03] [TIME: 00:17:02] One of the things that bothers me is we talked [17:05] about data processing for thirty years, we spend all our time talking about the processing hardware [17:10] and software, we paid no attention to the data -- And yet the data is our raw material -- [17:17] Our output is information, our product -- And we should be concentrating [17:22] on the data in the information. The hardware and software are, after all, only [17:26] the tools which we do the processing and should not occupied the primary position in our thinking. [17:33] It s high time, we began to turn our attention -- To the data and the information [17:39] that we re putting out -- I don t know how I m going [17:42] to persuade people to do it, but I ll try hard. There were a lot of things that we re pushing me [17:47] toward worrying about all this future business -- We ran the Mark computers all during world war. [17:54] Two -- I thought you might like to know that [17:57] the first computer bug is still in existence -- We were building Mark two the summer of [18:03] nineteen forty five. It was a hot summer in Cambridge and naturally, [18:08] since it was world war two we were working in a world war one temporary building [18:13] [TIME: 00:18:13] air conditioning [18:15] wasn t very good, no screens and Mark two stops we finally located the failing relay. [18:21] It was one of the big signal relays and inside the relay beaten to death by the [18:26] relay contacts was a moth about this big -- So the operator got a pair of tweezers and [18:31] very carefully fish the moth out of the relay put it in the log book put Scotch tape over and [18:36] below-below it her he wrote. First actual bug found -- [18:42] I know you ll be glad to know that the bug is still in the log book under the Scotch tape. [18:46] It s in the museum at the naval surface weapon center in Dahlgren Virginia -- [18:51] And I ve told that story a lot of times. It turned out some people didn t believe me, [18:55] particularly American Federation of information processing societies. [19:00] So, they made an expedition to Dahlgren and sure enough. [19:02] They found the first bug in the log book under the Scotch tape, so they took a picture of it [19:08] and last year, in the July 1981 issue of the Annuls of the history of computers. [19:13] They published a picture of the first bug. [TIME: 00:19:15] [19:16] And I think it s rather nice that the Navy is keeping a few of the early artifact like the [19:21] first bug and me in a few other things. -- However it finally got to be 1946 [19:29] and each one of us had, the war was over, and each one of us had [19:32] to decide what we were going to do next -- Now up to that time, the WAVES had always [19:36] been reservists and in forty six the Navy offered the opportunity to the [19:41] WAVES to transfer to the regular Navy. So naturally I applied for for transfer [19:45] to the regular Navy and I was turned down because I was too old. [19:50] The cut-off age was thirty-eight, and I was forty, and incidentally, [19:54] it s just as well to be told your too old when you re forty, because you go through [19:59] the traumatic experience and it never bothers you again after that. I really recommend it, highly. [20:07] However, I elected to remain in the reserves. Now back in those days, in the reserves, we had three [20:13] jobs to do: summer training duty, weekly meetings, and take correspondence courses. [20:17] [TIME: 00:20:17] We had to take correspondence [20:18] courses according to our designators -- I was then an ordinance officer -- [20:25] At present, thanks to the now defunct naval personnel, it turns out I m an aeronautical [20:29] engineer, but I don t worry about that. So I took ordinance courses and of course the [20:35] Navy was using all using up all the old manuals you ll at the end of the war, so I ve learned all [20:40] about big guns and gun turrets and everything we within phasing out of the Navy, though it may come [20:45] in handy again, I ran out of ordinance courses -- The only other courses that would credit for [20:51] my designated with a war college courses so absolutely terrified. [20:56] I sent for the first war college course and they sent me the first problem -- [21:01] I was to fuel a task force at sea in minimum time, and all I told me was how fast the [21:07] different ships could pump oil and receive oil. And of course I knew nothing about fueling. [21:12] Ships at sea -- But I had to do [21:15] something so I lined up an oiler in the carrier and start pumping from the oiler to the carrier. [21:20] [TIME: 00:21:20] Perfectly clear that [21:21] wasn t going to get me minimum time -- So I decided they must have given me the [21:25] rates for some reason I looked at those found. I could simultaneously pump oil to carrier [21:30] and carrier to destroyer and they d both be filling up because the rates were different -- [21:36] Now, somewhere along the line, somebody had given me a course in problem-solving [21:40] and they told me to always extend every solution. So I did I start pumping from the destroyer to a [21:46] Corvette. We still had something (laugh) -- That was all working beautifully -- [21:52] But that course also told me I must generalize every solution -- [21:56] Show I did on the other side of the oiler, or I pulled up [21:58] a cruiser in a destroyer and of Corvette. I ended up with half a task force all hitched up [22:03] with lines sailing down the middle of the ocean -- My problem is returned with the comment and [22:10] interesting solution -- I just decided that: [22:15] wasn t a way to fuel ships at sea -- Along came the next problem this time [22:19] and gave me a squadron. [TIME: 00:22:20] [22:21] of submarines, told me scout the Caribbean minimum time. Well I knew [22:24] less about submarines than I did about Oilers. So this time I called on my friendly computer [22:30] to help me and I used a random walk program for each of the submarines. [22:34] You should have seen that map. I covered at minimum time, it was beautiful. Only trouble [22:39] was I had those submarines cutting across each other; they made U-turns, one did a little [22:42] circle up here and came back. An interesting solution -- [22:49] I was even beginning to feel some sympathy for the poor guy at the war college that [22:52] had to read my solutions and along came the third one, and that was the important one -- [22:58] I was to make a plan to take an island -- And after I completed my plan, [23:02] I was to make two reviews of it. I was to review my plan in the light [23:07] of all possible enemy actions, all possible future events, and then I was to review the [23:14] cost of not carrying out the plan -- Two reviews which are critical to any [23:19] plan whatsoever that I keep finding them left off of our plans for computers -- [23:25] [TIME: 00:23:25] We have a very bad tendency [23:27] to base our plans for computers on the equipment we have in house and the things we re doing now. [23:33] And totally failed to review them in the light of the equipment that will be available [23:37] and the things that we will be doing -- I think the saddest praise I ever hear in [23:44] a computer installation is that horrible one "but we ve always done it that way." [23:51] That s a forbidden phrase in my office -- To emphasize the fact I keep a clock which [23:56] operates entirely counterclockwise -- Now the first day people meet it, [24:01] they can t tell time. By the second day, they discover what used to be 10 of is now 10 after, [24:05] they can tell time again. Normally it s not until the [24:08] third day that they recognize -- That there was never any reason [24:11] why clock should run clockwise that could just as well as run counter clockwise -- [24:19] There s no reason for the hands to go by the digits. [24:22] I have another clock that has a pointer and the digits go round on a drum. Tells perfectly good [24:26] time, course by now I have a digital clock -- [TIME: 00:24:29] [24:30] And my helpful crew gave me an hour glass -- But they sit there day in and day out and say: [24:36] never never, never in this office say, but we ve always done it that way. [24:42] Now, when it comes to carousels at airports, I can see a good reason why they run this way. [24:47] That s because most people are right handed and that s the way you grab your bag. [24:50] I still haven t found out why helicopter rotors go the way they do, but -- [24:55] I find it rather interesting -- "that we ve always done it this [24:59] way" seems to be so much embedded in things and it s the most dangerous phrase you can [25:04] use in a computer installation -- So hopefully, I ll give you each [25:11] one of your very small gift. I will promise you something, [25:14] if during the next 12 months any one of you says, "but we ve always done it that way", [25:20] I will instantly materialize beside you and I will haunt you for 24 hours -- [25:26] And see if I can get you to think again and I know it works, I ve already had over 70 letters [25:30] thanking me for honing people -- [TIME: 00:25:32] [25:33] I ll be there we ve got to accept the new things that are ahead -- [25:38] One of the major difficulties is the difficulty of changing people s minds -- [25:43] I had to give a presentation and for the EDP policy committee, the Joint Chiefs of Staff, [25:47] all admirals and generals -- I had to remind those gentleman [25:51] that they ve had piles of big reports sitting on their desk that they d had to read and absorb, [25:56] big decisions they had to make and they had not had time to keep up with the technology that was [26:02] changing overnight, and therefore they were going to have to learn to listen to their juniors -- [26:09] I m telling all the youngsters -- officer and enlisted -- [26:14] and civilian -- Never never never take the first no. [26:23] There are a certain number of people, business, industry, government, who always say no the first [26:28] time you suggest something new, because they re lazy, you know if they say yes they re going to [26:32] have to do something about it. [TIME: 00:26:33] [26:34] But there s another group, who are even more dangerous in a way, who always say no the [26:38] first time you suggest something new or different because they want to see if you believe it enough [26:43] to come back and ask again -- So never take the first "no", [26:48] always go back and ask again a matter of fact, I take about four "nos" and then I figure out [26:52] how to get around the guy, but -- That technique comes with age. [26:57] I ran into one of these guys during World War II in Buord. [27:01] After about two or three suggestions, I noticed he always said "no" to things, [27:05] the first time. So the next time I wanted to suggest something, I said: let s pretend [27:09] this is the second time I m presenting this -- I said you always say "no" the first time and [27:14] he looked at me with the funniest expression. I had him over the barrel from then on because [27:18] I just go and say this is the fourth time I m requesting this. [27:21] Let s just say "yes" now, -- So never never never take [27:27] the first "no" on a new concept -- It s terribly important that we listen [27:32] to our youngsters -- [TIME: 00:27:34] [27:35] Some very interesting things are happening in the Navy. [27:38] I know one case of a young Lieutenant junior grade who went aboard a ship -- Navy thought [27:41] it was too small to have a computer -- He took his own computer aboard, [27:45] he was an admin -- Pretty soon he had all [27:48] the ship s records in his computer, he was getting all the reports out on time; beautiful, accurate, [27:52] everything was just marvelous -- When he was transferred, [27:55] the captain had to buy his computer. [28:00] I know another case where the commander of a squadron was told [28:03] to take his squadron out to a carrier -- You found that when he did, he would have [28:07] to leave all his maintenance records in the naval air rework facilities in RF. [28:13] This didn t please him at all. He wanted to take and its records [28:15] of his planes with him -- So we went out and bought [28:18] himself an Apple where the assistance of an [28:20] ensign and a DP and the if he -- Borrowed, stole, liberated copying [28:28] his records from the North into is -- Apple, got a case for it, put it in the [28:34] space behind his seat, which is supposed to take his suitcase, and flew off to the carrier with all [28:39] of his maintenance records and a computer with which to keep them up to date. Every commander [28:44] of every squadron should have that. Somebody said, um, are you supposed to do that? He said, [28:50] I didn t ask. I long ago discovered -- of course, you don t all have the same advantage [28:56] I have -- but I long ago discovered that the best way to get something done was to do it -- [29:01] [TIME: 00:29:01] And if necessary, apologize -- [29:04] It s much easier to apologize. You have no idea, oh gee, I didn t, [29:09] "I couldn t do that" -- I can turn into the most [29:14] helpless old female you ever saw. We ve got to listen to our youngsters, [29:24] we ve got to do the new things, and it isn t too hard to apologize. [29:28] Believe me -- We had another case: [29:31] young electronic technician, first class, out in the Pacific fleet, build a computer. [29:36] The PR (manner?) we shipped thought this was terrific. [29:39] So we took a picture of the sailor and his computer and put it in the Navy [29:42] Times. Admiral Collins saw it. So I wrote a letter to the sailor and [29:46] congratulated him, and he sent it direct through the mail instead of sending it through channels. [29:52] So the sailor decided that the Admiral could write him direct, [29:54] he could write the Admiral direct. And he did. And he thanked the Admiral for as he pointed out, [30:00] he didn t know Admirals read Navy times, but he was glad they did. [30:03] [TIME: 00:30:03] He then went on for 10 pages, [30:05] both sides single spaced, and told the Admiral exactly what was wrong with the computers in the [30:10] Pacific fleet and what ought to be done about it. There s probably the best survey we d ever seen -- [30:16] So the Admiral reached out his hand and said ET1 (?? problematic), Pacific fleet to Norfolk. [30:21] He gave them three more ETs and some DPs, that s our programmers, [30:26] And some money, told them to build a computer. In four months time, [30:30] out of off-the-shelf components, they built it. Three small boxes, database management system [30:35] and everything, just beautiful. They set them up as the micro [30:38] evaluation group. It s under the Naval Regional Data Center in Norfolk -- [30:44] They ve run every micro on the country and run most of the software -- they know exactly what [30:48] s available and what you can do with it -- Anybody in the Navy thinking of getting [30:52] micro-computers can consult with them and they ll give them real good, solid help. [30:57] Writing the RFP or acquiring the computer that they need for that job. [31:03] Three, three-and-a-half, four months ago -- I ve forgotten just when -- they put [31:06] on a seminar on micro-computers. They didn t think they d really get very many people, [31:10] they hoped for a hundred people and had to cut it -- had to cut it off when they got three hundred. [31:14] [TIME: 00:31:15] They got a hall in one [31:17] of the local Norfolk buildings. They had booths. They leaned on [31:21] all the micro manufacturers each to bring in their micro, and they had- [31:25] Everyone loves micros. I think there were 27 or [31:28] something like that of them. Every one of those micros [31:30] running an actual Navy problem. So when the Navy came in, they could [31:34] see the micros doing their kind of problem. They ve got some marvelous speakers. [31:42] Probably one of the most successful seminars on micros I ve ever seen, [31:45] all put on by those young enlisted men. In fact, Slater, who s now chief, has [31:53] recently written an excellent paper: "Everything you ever wanted to know about microcomputers, [31:58] but didn t know who to ask". It s top notch. [32:01] You can get a copy from -- from -- RDAC Norfolk. Excellent job, all the questions you should [32:09] ask when acquiring a micro, and why the different answers apply to different things. [32:15] It s top notch for an individual wants to get a micro computer. [32:18] [TIME: 00:32:18] Or for a small installation, [32:20] like our small naval bases and so on that want to get a microcomputer. [32:23] It s a beautiful job, contributed a tremendous amount to the Navy. [32:29] We ve got to learn to listen to those young men. They re bright as they can be, [32:33] and they really know that equipment. And it s true of our young officers, [32:37] and our young enlisted men. We ve got to learn to listen to them. [32:42] Because the upward most people have been much too busy managing things [32:46] to keep up with the technical developments. There s something else that was driving me [32:52] towards the future and worrying about the future. When I met Mark 1 back in 1944, Mark 1 was 51 [33:00] feet long, 8 feet high, 8 feet deep. She was in a magnificent glass case, [33:07] designed by Norman Bel Geddes. and what s more, [33:11] she had 72 whole words of storage -- each word consisted of 23 decimal digits [33:19] and an algebraic sign. And in addition, she could do three additions every single second -- [33:26] [TIME: 00:33:26] Three times every second, she could get two [33:28] quantities from memory, add em together, and put the answer back. That sounds pitiful to you today, [33:34] but if you go back and look at the newspapers and magazines of that period, you ll find that [33:39] Mark One was the most remarkable tool that man had ever built because she was the first tool [33:44] that assisted the power of his brain instead of the strength of his arm, the very first one. [33:50] She did an addition in 333 milliseconds, 3 additions per second, 333/1000ths of a second. [33:58] We didn t stop there. There were a lot more [34:01] computers built during the rest of the war -- most of them under contract to the Department of [34:05] Defense at various universities. Not till 1951 did we have the first commercial electronic computer, [34:12] and that was the old Univac One. And a year ago goal at the National Computer Conference, [34:17] they celebrated her 30th birthday. She even got a birthday cake. [34:22] And UNIVAC 1 could do an addition in 282 microseconds, 282 millionths of a second, [34:30] and we were going a thousand times faster. [TIME: 00:34:33] [34:34] We didn t stop there. By 1964, out came the first [34:38] of the CDC 6400s, and it did an addition in 300 nanoseconds, 300 billionths of a second. [34:46] And we were again going a thousand times faster. Now, if you re a nut about the future, as I am, [34:52] naturally you have to try and write the next line -- see what it looks like. 19 question mark: [34:56] will we need an XYZ system that adds in 300 pico-seconds, 300 trillionths of a second [35:03] for a complete addition? Storage to adder, storage to adder, add em together and put [35:08] the answer back another thousand times faster? Answer is we need it right now for a couple of [35:15] problems, so what you needed very badly -- The population of the world is increasing. [35:22] That means we have to increase food supplies. The biggest assist we could give to increasing [35:27] food supplies would be better long term weather forecast. [35:30] Yes, you may remember a couple of years back they planted corn out in Iowa -- [35:35] [TIME: 00:35:35] Before it was fully rooted, [35:36] heavy rains came wash it all out that had to wait for second shipment of seed and fertilizer plant [35:43] again was delayed the early frost got it -- If they d known the rains were coming, [35:49] they could have delayed the first planting and would have had that crop. [35:52] Yeah, we do not today have a computer which will run a full-scale model of [35:57] the big heat (??problematic) engine which consists of the atmosphere and the oceans. [36:00] We haven t even tested all of our models. Now that didn t matter til a few years ago; we didn [36:06] t have the data to feed into those models -- The Navy was dropping radio-equipped buoys in [36:10] the rivers and the oceans to get more information; we were putting sensors on commercial airliners, [36:16] recorded on tape and took em off when they landed. But now we have the satellite photographs. [36:22] Those satellite photographs -- the landsat photographs -- are so darn good that when they [36:27] re fully enhanced by computer, we can actually tell how high the waves are out in the middle of [36:31] the Pacific; we can tell what the temperature of the ocean is 20 feet below the surface. Of course, [36:37] there s a catch -- [TIME: 00:36:39] [36:39] to fully enhance a satellite photograph takes 10 to the 15th power arithmetic operations -- that [36:46] s close to 3 days and our best computers and the weather s already happened. Yet [36:50] we desperately need that information. There s another area in which we re [36:55] going to need computers. The news magazines -- it s one that every so often they turn it up. [37:01] I think the Corps of Engineers worries about it, but nobody seems to really point at it very hard. [37:06] That s the question of management of water -- My sister lives in northern New Jersey. [37:15] A year ago spring, they were limited to [37:17] fifty gallons of water a piece, a day and they came around and looked at the water meters and [37:21] if anybody used more than that they fined them. Down in Norfolk, they began to run short of water. [37:27] Now, the city of Norfolk draws its water from wells, so they decided they had better drill [37:33] a couple more wells. And they got awful cute about it, they drilled them in the corner of [37:37] the naval base and thought they d get away with it -- but they were in Suffolk county. [37:42] [TIME: 00:37:42] So you know, Suffolk county [37:43] is suing Norfolk County for stealing their groundwater. Nobody s getting (the?) water, [37:47] of course. Down in [37:49] Florida they use so much water they opened huge sinkholes and dumped houses and cars into them. [37:55] Out in Colorado, the eastern half of the State s dried, the Western half has [37:59] money -- (I mean?) water -- So, um, same thing. So, um, [38:06] the Easterns think it d be a ducky idea idea to poke a tunnel through the Rockies, [38:09] and get water from the western half. No way the Westerners gonna give [38:12] their water to the nasty old Easterners! In fact, Colorado, Nevada, California, all [38:17] those states out in- out there are in the courts, fighting over who can draw how much groundwater [38:22] from where, and how much water from which river. Water supplies are going to be one of our major [38:29] problems of the future. We may even import [38:31] water from Canada, instead of oil. Can you imagine what kind of computer [38:38] power it s going to take to manage water, so that every individual in the United States gets his [38:43] fair share of pure water? [TIME: 00:38:44] [38:45] It s going to be one of the biggest jobs we ever tackle. [38:49] At the other end of the scale, we need the itty bitty computers. I m awfully fond of a small town [38:53] in New Hampshire -- used to have sort of a septic system and a great, big, open, burning dump. [39:01] Along came the EPA and said you can t do those awful things anymore. [39:04] We ll give you a large sum of money You will put in a (tertiary?) treatment [39:08] plant for the sewage and an incinerator in place of the dump, so they did. [39:12] They even had a parade with a band and everything when they dedicated the [39:15] incinerator -- they love parades in New England. And then they found they had another problem. [39:22] Because they took the EPA money, the nice, little, old lady who keeps the town records, [39:28] which used to be two lists, one a list of the taxpayers, checked them off paid taxes, [39:32] the other was a list of (?? problematic), she d check them off at town meetings. [39:35] But now she has to report to the township, the county, the state, [39:38] the federal government, EPA, OSHA, EEOC, IRS, Social Security, government reports. [39:43] Every one of them is arranged differently and totaled differently. And she s going to [39:48] have to have a computer just to get the government reports out. [39:52] [TIME: 00:39:51] And that s happening [39:52] to every small business, every doctor, every lawyer, and every small town across the country. [39:56] We re still going to need to the itty-bitty computers, everything from [40:00] the itty-bitty up to the great big ones. I said we re going to have some trouble [40:04] getting there. To explain that [40:07] I have to explain something about myself. I m an extraordinarily annoying employee. [40:13] I normally drive all of my bosses totally nuts, because I won t do anything until I [40:19] understand what I ve been told to do. So when you tell me to do something, [40:23] I start asking questions, until I get a clear picture of what I ve been told to do. [40:28] Well they told me that first computer was adding in milliseconds. So now I [40:32] naturally said what s a millisecond? Well, they told me it s a thousandth of [40:37] a second, and I had a problem immediately. I could see a second go by on the clock, [40:41] but darned if I could see a thousandth of it. So I said "please show me a millisecond". [40:47] And nobody, but nobody would show me a millisecond. [40:51] Time went on with me still fussing, until somebody stuck a finger on one of my programs, and said: [40:56] "Hey you wasted 3 -- 5 microseconds.: [TIME: 00:40:59] [41:00] And I said, "so what?". "What s a microsecond?" Well [41:03] they told me it was a millionth of a second. And again I had a problem. In the first place, [41:08] I didn t know what a million of anything was. The biggest check I d ever seen was [41:12] less than a thousand dollars. I didn t know what a million was, [41:15] and if I didn t know what a million was, I didn t know what a millionth was. [41:18] And I fussed and fumed. I wanted to know what a microsecond was. I got nowhere. [41:23] Pretty soon, over in the engineering building, they started talking about [41:26] circuits that act on nanoseconds, billionths of a second. Well that really had me on the ropes, [41:32] because in the first place I didn t know what a billion was, and I don t think most of those [41:36] guys up in Washington do either! And if you don t know what a billion is, how on Earth do you know [41:40] what a billionth is? I fussed and fumed. Finally, one morning, in total desperation, I called over [41:47] to the Engineering building and I said, "Please cut off a nanosecond and send it over to me." [41:52] And I ve brought you some today -- Now what I wanted when I asked for a nano second [41:57] was- I wanted a piece of wire, which would represent the maximum distance that electricity [42:03] could travel in a billionth of a second. Because it wouldn t really be through wire, it would be [42:09] out in space at the velocity of light. [TIME: 00:42:11] [42:12] So if you start the velocity of light and use your friendly computer, you discover [42:16] that a nano second is 11.8 inches long -- Maximum limiting distance that electricity [42:22] can travel in a billionth of the second -- Well, I was real happy with my nanosecond, I [42:28] looked at it from all angles- I thought about it. I looked at wall switches and counted the distance [42:33] some of those lights went on and I m like "gee these these may have taken [42:35] a couple thousand of nanoseconds" -- Finally at the end of about a week, [42:40] I call back and said: look, I need something to compare [42:42] this to. Could I please have a microsecond? microsecond? I ve only got one microsecond so [42:47] I can t give you each one. There s a microsecond. Nine hundred and eighty four feet. I sometimes [42:53] think we ought to hang on over every programmer s desk, so they ll know exactly what they re [42:57] throwing away when they throw away a microsecond. I hope you all get some of these nanoseconds. [43:03] I ve got lots of them with me. They re absolutely marvelous for explaining to [43:08] wives and children and -- admirals and generals. [TIME: 00:43:14] [43:12] And you may find yourself in a spot where you have to explain why two pieces of [43:21] equipment have to be close together -- Or explain to an Admiral why it takes [43:26] so damn long to send a message by satellite because they re an awful lot of nanosec -- [43:32] Very effective, they ll believe you. So you may need a nanosecond, [43:35] and I hope that gets them -- I hope you ll feel free to use this demonstration [43:39] If you need it. There s only one thing you have to be careful about if you re going to [43:43] use the demonstration. -- Normally, I put these in [43:46] my overnight bag and check it -- One day I put on my shoulder bag [43:49] and went down to national airport -- And it took me twenty minutes to [43:54] explain nanoseconds and microseconds before I could board an airplane. -- [43:59] So if you ve got them around with you be sure you check them. I ve [44:01] got lots of nanoseconds for you here -- I bet you didn t know and nanoseconds [44:06] came different colors, but they do -- But I said I wanted to add in 300 picoseconds. [44:14] Now a picosecond is a thousandth of a nanosecond. [44:19] [TIME: 00:44:18] The best way to make picoseconds [44:21] is get one of those big pepper grinders, and you can make picoseconds all over the table. [44:26] 300 picoseconds is going to be a third of a nanosecond. [44:30] And there s my problem. I haven t got enough distance to get from this- add this or add [44:35] the two together and put the answer back. I m beginning to push the velocity of light. [44:41] Now Dr. Einstein very carefully explained to us that when matter obtains the velocity of light, [44:45] matter turns into energy. It goes poof -- And of course, I m perfectly willing to [44:49] admit that our bright, young engineers are going to get beyond the velocity of light -- [44:53] They re going over into that anti-universe, where they have white holes and talk to all the Clarks [44:57] and left Johnson blue-ons and everybody else -- But not in the next five years, and I need [45:04] that computer before then. So what am I going to do -- [45:09] Well I could use my common sense -- Except that seems to be the last thing we [45:13] ever use in connection with computers. Qualify won t use common sense. [45:18] [TIME: 00:45:18] Maybe I can use history. [45:20] Back in 1976 we got well accustomed to looking at early history. Let s try that. [45:26] Now, back in the early days of this country, when they moved heavy objects [45:29] around, they didn t have any Caterpillar tractors, they didn t have any big cranes. [45:35] They used oxen. And when they got a great big log on the ground, and one ox couldn t budge the darn [45:41] thing, they did not try to grow a bigger ox. They used two oxen. [45:51] And I think they re trying to tell us something. When we need greater computer power, the answer [45:56] is not get a bigger computer -- it s get another computer. [46:00] Which, of course, is what common sense would have told us to begin with. [46:03] Incidentally, common sense is a legitimate scientific technique. [46:07] The mathematician Polya, who worked at Princeton- he s the man who wrote the [46:12] two volume text on techniques of problem solving- he also wrote a nice little anchor paperback, "How [46:17] to Solve It". And one entire chapter is devoted to the use of common sense and solving problems. [46:25] [TIME: 00:46:24] Yet we sometimes forget to use it. [46:28] So the answer is that to get the computer part, we re going to need -- we re going to have to [46:31] build -- systems of computers. Of course, the first answer anybody ll give you to that is [46:36] that ll cost too much, but it won t anymore. The cheapest, complete computer you can buy [46:41] today is probably the old Intel 80-21, the first of the 4-bit computers on a chip: [46:48] 64 words of data storage, 1000 words of program storage -- those are down to 13 [46:52] cents a piece if you buy a hundred of em -- There s nothing to stop us from building [46:56] systems of computers. Course I walked into [47:00] one difficulty the minute I proposed the idea. I decided that if I was going to have systems of [47:05] computers, I d need three dimensional flow charts. So I got some plastic plates and I could draw [47:11] charts on each one, pile them up, looked like three dimensional chess. [47:15] When I connected between the plates, I used little pieces [47:17] of string and Scotch tape, but they fell off. Finally I remember tinker toy and got a nice [47:23] tinker toy set and it had to square things and round things and sticks to put them together and [47:27] I started building three-dimensional flow charts. [TIME: 00:47:30] [47:30] But I ran out of pieces -- So I wrote out a requisition [47:34] for two large tinker toy sets -- Two days later, here s the boss: [47:40] "Well, Grace, what are we doing now?" -- I have a better suggestion for you today: [47:48] get some of those sets. the chemist used to show you molecules. Red balls [47:52] can be computers, blue balls can be databases, yellow balls database managers, green balls [47:57] switches. And you can build a model of a system of computers and how they communicate and which ones [48:04] are connected to which others. And you re going to have to get out of the plain of the paper. You can [48:09] t write, draw em on flat paper anymore. They ve got to be in three dimensions, [48:13] and you re going to have to explain to people what these systems of computers are doing, [48:18] and I think the best solution is get one of those chemistry sets if you can. -- [48:22] Of course you may have explain why you re ordering one but -- [48:26] At least I warned you what happens when you ask for such things out of the thin air. --