7 IoT History: Paradigm Evidence

7.1 Start With the Decision

IoT history is more than a list of dates. Each shift must link a new technical ability to the decision or service it changed.

7.2 Route Overview

This is part 1 of 3. Continue with IoT History: Adoption and Cost.

7.3 Part Objectives

• Connect major IoT eras to changes in sensing, networking, and control.
• Evaluate a historical paradigm claim from dated technical evidence.

7.4 Start With the Story

A product team has a useful connected idea, but an expert rejects it because today’s habits make the idea look unnecessary. The team must decide whether that warning exposes a real limit or repeats an old pattern of judging a new system by the system it may replace.

7.5 Overview

This route follows communications and computing shifts to show why experts miss changing boundaries, how adoption grows, and how to reframe a proposal without pretending history guarantees success.

This is part 2 of 2. Review IoT History: Forecasts and Early Lessons when you need the first route.

7.6 Learning Objectives

By the end of this chapter, you will be able to:

• explain how paradigm blindness distorts technology forecasts
• compare adoption and cost evidence without treating analogy as proof
• apply the SHIFT framework to a skeptical IoT proposal

7.7 Chapter Roadmap

• Start With the Story
• Overview
• Sir William Preece, 1878
• A Pattern Across Centuries
• Telephony to IoT Evolution
• Why Experts Miss Paradigm Shifts

7.8 Sir William Preece, 1878

“The Americans have need of the telephone, but we do not. We have plenty of messenger boys.”

This wasn’t ignorance — it was expertise applied to the wrong paradigm. Preece was a brilliant engineer who understood telegraphy perfectly. His error was evaluating a paradigm-shifting technology through the lens of the paradigm it would replace. He compared the telephone to telegraph delivery (where Britain excelled) rather than imagining how instant voice communication would create entirely new social and business patterns.

One useful way to frame that error is to look one step earlier than the telephone. Spoken language made coordination immediate but local. Gutenberg’s movable type made knowledge durable, cheap to copy, and able to travel without the speaker. Telephony then made conversation remote and synchronous. Each transition changed both the medium and the behavior around it. For IoT, the same discipline matters: do not judge a connected object only by the old manual interaction. Ask what changes when status can be sensed, copied, routed, and acted on without waiting for a person to be physically present.

The birth of the telephone is also a systems lesson, not only an inventor story. Alexander Graham Bell’s early instrument turned voice pressure into a changing electrical signal; practical service then needed a transmitter, receiver, battery, local loop, switching, and eventually long-distance operating rules. A tin-can telephone can show the intuition that a medium carries a varying signal, but the Bell System became valuable when that signal path was reliable enough for households and firms to organize around it. The same pattern continued as printed media moved into digital readers: the object still looked like “a book” at first, but storage, search, synchronization, and network delivery changed the surrounding service.

The control-plane lesson appears when the network has more than two people. If every caller needed a direct line to every other caller, the number of pairs would grow as N * (N - 1) / 2; a neighborhood of 1,000 people would need 499,500 pair connections. Telephone exchanges changed the shape of the problem. A switchboard or central office let each subscriber attach to a smaller shared switching system, where an operator, a Strowger step-by-step switch, a crossbar switch, and later stored-program control selected the path for the call. That is the old telephony version of separating coordination from payload: control logic decides who should be connected, while the established circuit carries the conversation. Modern IoT systems repeat the pattern whenever identity, routing, authorization, and fleet policy must scale without giving every device a permanent private path to every other device.

The data-plane lesson appears after that coordination starts to work. Early telephone adoption grew from 49,000 lines in 1890 to 600,000 in 1900, 2.2 million in 1905, and 5.8 million in 1910, so the payload path had to become an engineered geography rather than a demonstration circuit. Metallic-circuit route maps, interurban trunks, transcontinental lines, and transatlantic cable landing points show the hidden work behind “talking at a distance”: wires, repeaters, amplifiers, rights-of-way, power, landing stations, repair practice, and operational monitoring. Lee de Forest’s Audion mattered in that story because amplification changed how far a weak signal could travel before the conversation became unusable. For IoT, the analogy is practical: a clever control service is not enough if gateways, links, brokers, queues, storage, and backhaul cannot carry telemetry and commands reliably at the scale adoption creates.

Broadcast networks changed the shape again. A switched telephone call connected selected endpoints; broadcast radio sent one transmission to every receiver in range. That required both invention and industry. De Forest’s Audion made weak radio signals more usable, Edwin Armstrong’s feedback and regenerative receiver work sharpened amplification and tuning, and later FM showed that moving information by frequency variation could improve noise behavior compared with amplitude-only thinking. David Sarnoff and RCA turned that technical base into a mass-market receiver, programming, and spectrum business where the network’s value depended on useful content, reliable reception, and operating scale. The IoT lesson is not that sensor networks are broadcast businesses. It is that shared radio systems need the same layered discipline: physical signal quality, channel planning, receiver behavior, gateway capacity, message priority, and application value all have to line up before a fleet can feel like infrastructure rather than a clever demo.

Television made that network-and-content dependency visible at national scale. RCA, NBC, CBS, ABC, PBS, and their affiliates were not valuable because a transmitter existed in isolation; they were valuable because receivers, studio cameras, live events, programming schedules, rights, advertisers, and long-haul distribution could be aligned. A 1950 television network map compared with later national coverage shows the same adoption curve as many connected systems: first the technical reach is sparse, then the service becomes durable when the content and operating model justify more infrastructure. For IoT, “content” may be telemetry, alarms, state estimates, or control actions, but the rule is similar: a network that moves data without a valuable use case remains a transport demo.

AT&T and Bell Labs show the next layer of the same history. Sampling turned continuous speech and sensor signals into digital records; speech coding made voice small enough for constrained links; Claude Shannon’s information theory gave engineers a language for capacity, noise, and uncertainty; the transistor made electronic switching and amplification compact; and C plus Unix made portable systems software practical. The Bell Labs transistor story, from Bardeen, Brattain, and Shockley to practical switching circuits, is also the bridge from room-scale electronic equipment to minicomputers, microcontrollers, phones, cameras, radios, and other endpoint devices. Those topics now live in separate technical chapters, but historically they belonged to one infrastructure problem: how to turn physical signals into reliable, computable, networked services.

That story also has an institutional side. Theodore Vail’s regulated-monopoly Bell System argued that a telephone network became more useful when service was universal, reliable, and centrally coordinated; the same logic gave AT&T stable revenue and obligations that could support long-horizon Bell Labs research. The later breakup of AT&T changed that industrial structure, but not the lesson for IoT infrastructure: network value, regulatory constraints, operating scale, and research investment are coupled. A fleet platform can fail if it treats connectivity as only a technical feature while ignoring who funds the shared infrastructure, who governs access, and how the network keeps improving.

The breakup was not a single switch flipped overnight. The 1914 Kingsbury Agreement connected AT&T long-distance service to independent exchanges, the 1921 Willis-Graham Act allowed more local consolidation under regulated-service logic, and the Justice Department’s 1949 Western Electric case eventually kept AT&T out of the general computer business while protecting its telephone-equipment role. Carterfone in 1968 changed the attachment boundary by allowing non-AT&T devices on the network, and the 1974 antitrust case led to the 1984 divestiture. Later recombinations among Bell Atlantic, NYNEX, GTE, MCI, US West, Qwest, Ameritech, Southwestern Bell, Pacific Telesis, BellSouth, Verizon, SBC, and the new AT&T show that network markets keep reorganizing even after a formal breakup. For IoT, that history is a warning: ownership boundaries, device-attachment rules, platform access, and regulatory bargains can shape architecture as much as a radio or protocol choice.

Bell Labs’ research impact also came from hard infrastructure constraints, not from research being detached from operations. Materials science, solid-state electronics, microwave and optical communication, Unix and C, CCD imaging, laser cooling, quantum-effect work, broadband copper and optical access, cellular systems, heterogeneous networks, and cloud-network ideas all answered problems created by real communication scale. The practical lesson is that a strong IoT research program should be tied to concrete “10x” system challenges: cheaper deployment, lower power, better capacity, safer attachment, stronger interoperability, or more reliable operation under messy field conditions.

C and Unix are part of that same platform history. Ken Thompson and Dennis Ritchie built Unix at Bell Labs, Ritchie created C, and Brian Kernighan and Ritchie’s The C Programming Language helped make systems programming portable enough to travel across machines. AT&T Unix System V, BSD Unix, Linux, Android, macOS, and iOS are not one identical operating system, but they show how a small set of abstractions — files, processes, permissions, pipes, sockets, and portable C interfaces — became the software substrate for servers, gateways, phones, and development boards. A Qualcomm DragonBoard 410c or similar embedded Linux board is therefore not just “a board with chips”; it is the transistor, operating-system, compiler, and network stack story condensed into a bench-top IoT endpoint or gateway prototype.

That history also explains why IoT has had several names before the current shorthand settled. Mark Weiser’s ubiquitous-computing work at Xerox PARC framed the goal as computing embedded into everyday environments until it feels natural. Neil Gershenfeld’s MIT Media Lab work and Kevin Ashton’s Auto-ID framing shifted attention from people browsing the Web to physical things using networked identifiers and data. The ITU’s 2005 Internet report then described networked objects such as appliances, vehicles, RFID tags, and sensors as part of a new communication era. The European Commission’s 2009 action plan emphasized objects with identifiers, IP reachability, sensors, and actuators inside larger systems. Cisco’s later “Internet of Everything” language widened the lens again to people, process, data, and things. For engineering review, these labels are less important than the boundary they keep repeating: small devices, low power, sensing or actuation, wireless communication, internet reachability, programmability, and some local or system-level autonomy must work together before the idea becomes a dependable product.

7.9 A Pattern Across Centuries

The dismissal of transformative technology is not limited to telephones and mobile phones. Consider these additional examples that reveal the depth and universality of paradigm blindness:

Each case follows the same pattern: an expert with deep knowledge of the current system fails to anticipate how a new technology will create entirely new categories of use.

7.10 Telephony to IoT Evolution

The evolution from telephony to IoT reveals a pattern of expanding connectivity that established players consistently underestimate:

To test telephony to iot evolution, open the diagram in Figure 7.1. Recurring Pattern of Technology Dismissal supplies one named condition; STAGE 1 supplies the necessary comparison for the same dismissal pattern repeats: experts judge new connectivity by the old job, while adoption grows around new behavior.

Locate Recurring Pattern of Technology Dismissal on Figure 7.1 before checking STAGE 1. The visual’s third anchor, New Idea, completes the same dismissal pattern repeats: experts judge new connectivity by the old job, while adoption grows around new behavior. Carry Recurring Pattern of Technology Dismissal into telephony to iot evolution; use New Idea as its limiting condition.

The Pattern of Dismissal:

7.11 Why Experts Miss Paradigm Shifts

The following diagram illustrates the two parallel tracks that occur when a new technology emerges. Experts evaluate it using existing frameworks (left path), while the technology actually creates entirely new possibilities (right path). Both paths converge at “Paradigm Blindness” — the gap between expert predictions and actual outcomes.

Figure 7.2 makes why experts miss paradigm shifts inspectable through Why Experts Miss Paradigm Shifts and Expert Evaluation Track. Those diagram labels establish the scope of paradigm blindness separates the expert’s old-frame evaluation from the market’s new behavior path.

Use Expert Evaluation Track to test Why Experts Miss Paradigm Shifts in the diagram at Figure 7.2. Then inspect Actual Adoption Track as the final qualifier on paradigm blindness separates the expert’s old-frame evaluation from the market’s new behavior path. That sequence keeps why experts miss paradigm shifts tied to what is visibly labelled.

7.12 Continue to the Next Part

Carry this evidence into IoT History: Adoption and Cost, which begins with The Anatomy of Paradigm Blindness.