Who Saw the Connection? #05 — G-SHOCK × A Bouncing Ball × Engineering Breakthroughs
In the early 1980s, Kikuo Ibe and a small team at Casio spent roughly two years trying to make a watch survive something watches weren't supposed to survive.
They built more than 200 prototypes. Ibe dropped them from a third-floor bathroom window at Casio's research facility. Components broke, designs changed, more prototypes followed, and eventually the team reached that particularly unpleasant stage of engineering where you're no longer sure whether the next iteration is progress or simply a more expensive way of confirming that the previous one failed.
The breakthrough didn't come from another watch.
It came when Ibe saw children playing with a rubber ball.
That observation helped produce G-SHOCK.
And strangely enough, solving the engineering problem wasn't even the end of the story. Casio still had to convince people that they wanted the thing.
It Started With a Broken Watch
The story begins in 1981 with an accident that was completely ordinary at the time.
Ibe owned a watch given to him by his father. One day, it fell from his wrist and broke.
Today, that sounds like a product failure. At the time, it wasn't necessarily seen that way. Wristwatches were precision instruments. You were expected to treat them carefully. Thinness and elegance were desirable; surviving serious physical punishment wasn't generally part of the bargain.
There is an interesting habit in engineering where, if a limitation survives long enough, we eventually stop describing it as a limitation.
We start describing it as proper usage.
Don't drop the watch. Don't send requests that quickly. Don't run that query during peak hours. Don't let the payload get that large. Don't deploy on Friday.
Some of those rules exist for excellent reasons. Others are historical compromises that quietly acquired the status of natural law.
Ibe questioned one of them.
He submitted a proposal internally at Casio with a remarkably simple objective: a watch that wouldn't break when dropped.
Casio approved the idea, and Ibe joined a small development group called Project Team Tough.
Then they made the requirement considerably less reasonable.
Triple 10 Was an Almost Rude Engineering Requirement
The development philosophy became known as Triple 10:
- survive a 10-metre drop
- withstand 10 bar of water pressure
- target a 10-year battery life
That combination matters.
Casio wasn't merely asking engineers to improve one specification. A wristwatch contains a quartz timing mechanism, electronics, an LCD, a battery and multiple connections, all packed into something small enough to wear comfortably.
Shock resistance alone is difficult.
Water resistance alone is difficult.
Long battery life imposes another set of constraints.
Now solve all of them without producing something approximately the size of a microwave.
The original production G-SHOCK wouldn't literally achieve every Triple 10 number. The DW-5000C actually exceeded the water target with 20-bar resistance, while its specified battery life was seven years. Triple 10 was the development ambition that shaped the project rather than a literal specification sheet for the first model.
That distinction is important because the mythology around successful products tends to become cleaner than the engineering that created them.
The real story is better.
The requirement was aggressive enough that the existing idea of a wristwatch stopped being particularly useful.
Then They Started Throwing Watches Out of a Window
Casio says Project Team Tough produced more than 200 prototypes over roughly two years.
Testing shock resistance initially involved a beautifully direct piece of engineering equipment:
a third-floor bathroom window.
Ibe repeatedly dropped prototypes from roughly ten metres above the ground at Casio's research facility.
Something would break. The team would examine it, reinforce it and build another version. That prototype would survive one failure mode and reveal another.
They experimented with cushioning. They added rubber. They strengthened vulnerable components. At one stage, the protective structure became so large that Casio describes a prototype approaching the size of a softball.
This is where the number “200 prototypes” is often turned into a motivational story.
Keep trying.
Never give up.
Prototype number 201 might change your life.
That's pleasant advice. It also misses the most interesting part of the engineering.
The prototypes weren't valuable because there were 200 of them.
They were valuable because the failures were accumulating information.
Strengthen one component and the impact finds another path.
Protect that component and something else becomes the weak point.
Add enough protection and you've technically saved the watch by turning it into an object nobody wants to wear.
Eventually, the failures were telling Ibe that he might be solving the wrong problem.
Then He Saw a Child Bouncing a Ball
According to Casio's account, development eventually reached the point where Ibe gave himself one final week to find a solution.
On the final day, a Sunday, he went to a park near the research facility.
Children were playing with a rubber ball.
Nothing about that scene had anything obvious to do with watches. Nobody was conducting an experiment. The children were not unknowingly participating in Casio's R&D program.
But Ibe noticed something.
When the ball hit the ground, its exterior absorbed and deformed around the impact while its centre remained comparatively isolated from the collision.
That changed the question.
Until then, much of the effort had been directed toward making the watch's individual components capable of surviving shock.
The ball suggested another approach:
What if the important components didn't have to take the impact directly at all?
Instead of trying to make the mechanism indestructible, isolate it.
That idea contributed to the hollow, shock-resistant structure behind G-SHOCK. The watch's critical module could effectively float inside the protective case, reducing the amount of impact energy transmitted directly into the electronics.
The breakthrough wasn't stronger components.
It was a different relationship between the components and the force trying to destroy them.
Millions of people had watched children bounce rubber balls.
Ibe saw shock isolation.
That is the moment that makes this a Who Saw the Connection? story.
The Best Debugging Sometimes Changes the Question
There is a software version of the 200 broken watches.
A service starts timing out, so we increase the timeout.
Now requests survive longer but consume connections, so we increase the connection pool.
That increases pressure on the database, so we scale the database.
Retries begin amplifying traffic, so we add backoff.
Then we add caching.
Then somebody proposes another queue.
Six weeks later, the architecture diagram looks like it has developed a stress disorder.
Every individual change may be reasonable. The danger is that we can become extremely good at solving the latest symptom without reconsidering the model generating those symptoms.
Ibe could have continued reinforcing components.
Instead, the bouncing ball gave him another abstraction.
The question changed from:
How do I make every component survive impact?
to:
How do I stop the impact reaching the components?
That distinction appears everywhere in serious engineering.
Don't make the downstream service infinitely tolerant of duplicate requests if you can make the operation idempotent.
Don't keep increasing worker capacity if the real problem is uncontrolled upstream demand.
Don't repeatedly repair corrupted state if the architecture allows invalid state to exist unnecessarily.
Sometimes the breakthrough isn't a better answer.
It's discovering that you've been asking the wrong question.
In 1983, They Finally Built It
The first G-SHOCK, the DW-5000C, launched in April 1983.
It looked like the engineering problem that had created it: thick, protected, functional and unapologetically different from the slimmer watches popular at the time.
Two years of work had produced something genuinely unusual. The watch could tolerate punishment that would have destroyed conventional watches, and the structural thinking behind it would become foundational to the G-SHOCK family.
This is where the movie version ends.
The engineer refuses to give up. The impossible product finally works. Customers immediately recognize its brilliance. Inspirational music arrives precisely on schedule.
Actual markets have a crueler sense of humour.
The G-SHOCK initially struggled in Japan.
Casio's own retrospective describes a market where thin watches were mainstream and the bulky G-SHOCK wasn't immediately embraced. One person involved with the project later recalled that there was “almost no reaction at all” in Japan initially.
Think about that.
Two years.
More than 200 prototypes.
A genuinely different architecture.
A product that solved something people had largely accepted as unavoidable.
And the market essentially responded:
That's quite a large watch.
Technical achievement and market acceptance, it turns out, are completely different engineering problems.
America Saw Something Japan Didn't
The G-SHOCK story became stranger when the watch reached the United States.
Its ruggedness made immediate sense to people whose jobs or lifestyles were hard on equipment. Casio later identified early adoption among firefighters, police officers, military personnel and other professionals working in demanding environments.
The same characteristic that made the watch seem unnecessarily bulky to one audience made it useful to another.
Then Casio's American marketing operation found an exceptionally efficient way of explaining the product.
They used a G-SHOCK as an ice-hockey puck.
A 1984 television advertisement showed a player taking a shot with the watch. The goalkeeper caught it. The G-SHOCK survived.
This was a fantastic advertisement partly because some viewers thought it was nonsense.
A precision electronic instrument surviving a hockey slapshot sounded suspiciously convenient for a commercial.
Questions about the claim reached an American television program that investigated potentially misleading advertising. The program recreated the test.
The watch survived.
Casio's account says they went further and placed a watch on a road before running over it with a large truck.
Still working.
Casio had spent years engineering a difficult-to-believe property into the product.
Skeptical television producers accidentally gave them something even better than advertising:
independent proof.
If Your Claim Sounds Extraordinary, Stop Describing It
There is a wonderfully practical lesson here for anyone trying to build anything.
Imagine Casio advertising the G-SHOCK like this:
Featuring an innovative hollow-case architecture and advanced shock-resistant construction for exceptional durability.
Perfectly accurate.
Completely forgettable.
Now compare it with:
Here's our watch. We're going to use it as a hockey puck.
You understand the product in approximately three seconds.
Technology is full of products whose strongest characteristics are buried under adjectives.
High-performance.
Enterprise-grade.
Privacy-first.
AI-powered.
Scalable.
Resilient.
After enough years in software, these words develop a remarkable ability to pass through the human brain without disturbing anything on the way.
If the thing you built is genuinely unusual, demonstrate the unusual part.
If you built a privacy-first developer tool that processes data locally, show the network tab while somebody processes a sensitive file.
If your coding-agent plugin claims to prevent bloated AI changes, show a 600-line patch becoming 40 lines while preserving the requirement.
If your architecture dramatically reduces latency, run the workload.
If you're interviewing for an architecture role, don't spend fifteen minutes saying you're good at architecture. Show a difficult decision, the alternatives you rejected, the failure mode you were protecting against and what happened in production.
Proof travels farther than adjectives.
G-SHOCK happened to have one of the greatest product demonstrations imaginable.
Hit it.
Still works.
No architecture diagram required.
Then Japan Imported Its Own Idea Back
By the late 1980s, something unexpected was happening.
G-SHOCK was gaining an identity in the United States that it hadn't originally possessed in Japan.
Its toughness had practical value for people in demanding professions, but the watch also began spreading through sports and youth culture. Skateboarders, snowboarders, surfers and other communities found something appealing in the same rugged design that had once worked against it.
Then that image crossed the Pacific.
Casio executives later described noticing Japanese G-SHOCK sales increasing around 1989–1990 and investigating what had changed.
Their conclusion was unusually fascinating.
It was a reverse import.
The watch had been designed in Japan, struggled to find enthusiasm there, acquired popularity and cultural meaning in America, and then returned to Japanese consumers through magazines and American cultural influence.
Casio eventually leaned into this deliberately. Its Japanese marketing emphasized the watch's American popularity, including campaigns built around the message that America loved G-SHOCK.
The engineering hadn't suddenly improved during the flight back to Japan.
The product was fundamentally the same.
What changed was what the product meant.
The Same Product Can Be Wrong in One Room and Right in Another
This may be the part of the G-SHOCK story I find most useful outside product development.
We tend to interpret rejection as a verdict on quality.
Sometimes that's exactly what it is.
But rejection can also contain another message:
wrong audience.
G-SHOCK's toughness mattered immediately to people whose watches were exposed to physical punishment. Later, that toughness acquired another meaning among sports and youth communities. Eventually, the chunky design itself became part of the fashion.
Same watch.
Different people saw different value in it.
That happens in careers constantly.
An engineer can work somewhere that values ticket throughput above everything else. Their habit of thinking about architecture, failure modes and long-term maintainability is treated as unnecessary complication.
Move that same engineer into an organization struggling with distributed systems, platform reliability or technical strategy and the trait that previously looked like overthinking may become exactly why they were hired.
The engineer didn't suddenly become smarter on Monday.
The room changed.
The same thing happens to ideas. An open-source project can receive almost no attention because it was shown to the wrong developer community. An article can disappear on one publishing platform and spread rapidly on another. A product aimed at enterprises can fail while individual developers quietly love it.
The dangerous conclusion is:
Nobody wants this.
Sometimes the more accurate conclusion is:
Nobody here wants this.
Those sentences are separated by one word.
Careers and companies can be separated by the same distance.
But “Wrong Audience” Can Become a Very Comfortable Lie
There is an obvious trap here.
If nobody likes what you've built, you cannot spend the next five years declaring that society has simply failed to recognize your genius.
Sometimes the product is bad.
Sometimes the feature isn't useful.
Sometimes your résumé isn't communicating enough evidence.
Sometimes the article is boring.
Sometimes the side project solves a problem nobody actually has.
The G-SHOCK lesson isn't to ignore rejection.
It is to diagnose rejection correctly.
Ask what the evidence says.
Does the underlying thing work?
Can you demonstrate the value?
Has anyone independently found it useful?
Does another audience respond differently?
Are people rejecting the capability itself, or the way you've positioned it?
G-SHOCK accumulated evidence.
The watch survived punishment. Professionals bought it. American sales grew. Different communities independently found reasons to wear it.
That evidence justified reconsidering the market.
Without evidence, “wrong audience” is merely a pleasant story we tell ourselves.
This is why careers, products and engineering failures all require roughly the same uncomfortable skill:
separating persistence from denial.
Triple 10 Was Really a Bet Against Incremental Thinking
There is another reason I like the Triple 10 story.
Imagine Casio beginning with the existing watch architecture and asking what improvement seemed reasonable.
Perhaps they could make it 20% more resistant to shock.
Add some cushioning.
Improve the case.
Strengthen a few components.
That could have produced a perfectly respectable watch.
It probably wouldn't have produced G-SHOCK.
Triple 10 approached the problem from the other direction. It described the desired outcome first and allowed that outcome to make the existing architecture uncomfortable.
Software requirements often get negotiated in reverse.
We quietly shape the requirement around whatever system already exists.
“The database can't support that.”
“Our deployment model doesn't work that way.”
“The framework makes that difficult.”
Those are useful engineering constraints. Ignoring reality is not architecture.
But occasionally the requirement is telling us something else:
the architecture is answering an old question.
Good engineering judgment is knowing when a constraint should be respected and when the constraint itself deserves investigation.
Ibe could have produced a stronger conventional watch.
Instead, the requirement eventually forced him to reconsider what “protecting a watch” actually meant.
Two Hundred Attempts Are Useless If Attempt 201 Learns Nothing
This is where I would resist turning the G-SHOCK story into motivational wallpaper.
“Never give up” is incomplete advice.
If prototype 198 teaches you exactly what prototype 12 taught you, you're not demonstrating resilience. You've developed a remarkably expensive hobby.
The useful part of failure is the information it produces.
One component breaks. Strengthening it exposes another weak point. More cushioning makes the product impractically large. Eventually enough evidence accumulates that the original model becomes difficult to defend.
Then something has to change.
That applies far beyond engineering.
Twenty rejected job applications may mean you need to send twenty more. They may also mean your positioning isn't working.
Six months of low product adoption may mean marketing needs more time. It may also mean you've misunderstood the problem.
Five architectural fixes may mean the sixth needs more effort. They may also mean you've been fixing the same symptom five different ways.
Persistence matters enormously.
But persistence without model correction is repetition.
The difficult skill isn't refusing to quit.
It's understanding what the failure is trying to tell you before deciding what to do next.
The Ball Is Still My Favourite Part
For all the marketing, cultural and career lessons hiding inside G-SHOCK, I keep coming back to the rubber ball.
Because Ibe wasn't studying shock-resistant products when the breakthrough appeared.
He was watching children play.
A bouncing ball and a wristwatch share almost nothing at the level of appearance.
The connection exists one level deeper.
The exterior experiences the collision.
The centre is protected.
That's transferable.
This ability to recognize the structure of a problem somewhere that uses completely different objects, language and assumptions is one of the most valuable forms of thinking I know.
Toyota engineers could look at supermarkets and think about manufacturing flow.
Hospital teams could look at Formula 1 pit stops and think about patient handovers.
Japanese railway operators could turn a simple physical gesture into a mechanism for reducing human error.
And a watch engineer could look at a child bouncing a ball and stop thinking about stronger watch components.
The world is full of solved problems wearing the wrong uniform.
Sometimes expertise means knowing your field extremely well.
Sometimes it means looking away from your field long enough to notice that somebody else has already solved the shape of your problem.
Who Saw the Connection?
G-SHOCK eventually became one of Casio's defining products. By 2017, cumulative shipments had passed 100 million units, and Casio announced that the brand surpassed 150 million watches shipped worldwide in 2024.
Looking backward, success makes the path appear almost inevitable.
It wasn't.
There was a broken watch.
An unreasonable requirement.
A bathroom window.
More than 200 prototypes.
A design that kept failing.
A child bouncing a ball.
A product Japan initially didn't particularly want.
An American hockey commercial people thought was fake.
A television program that accidentally became product validation.
And eventually, Japan rediscovering a Japanese watch partly because America had taught it to look at the product differently.
That isn't a clean story about perseverance.
It's a much more useful story about seeing differently.
When the prototypes kept breaking, Ibe eventually changed how he saw the engineering problem.
When the Japanese market didn't respond, America saw a different use and identity for the product.
When people didn't believe the advertising, demonstration replaced description.
And when the product returned to Japan, consumers saw something in it they hadn't seen the first time.
That's why the rubber ball matters.
Hundreds of prototypes had already told Ibe that his current answers weren't enough.
The ball helped him ask a different question.
The next time something you've built isn't working—whether it's software, a product, an idea or even your career—the useful question may not immediately be:
How do I try harder?
It might be:
What am I still looking at the same way?
Because sometimes the breakthrough isn't hidden in another hundred attempts.
Sometimes it's bouncing around in a park.
Sources & Further Reading
Casio's official G-SHOCK history documents Project Team Tough, the approximately two-year development effort, more than 200 prototypes and the shock-resistant structure that emerged from the project.
Casio's history of the original 5000/5600 family describes Ibe's repeated drop tests from the third-floor bathroom window, the increasingly large prototypes and the observation of children playing with a ball that helped lead toward the floating-module structure.
Casio's material on Triple 10 documents the original development ambition and helps distinguish that philosophy from the literal specifications of the first DW-5000C.
The Japanese Patent Office has also documented the development of G-SHOCK, including the hollow structural concept associated with Ibe's observation of a bouncing ball.
Casio's corporate retrospective and integrated reporting provide the particularly interesting second half of the story: weak initial reaction in Japan, American adoption, the hockey-puck demonstration, growth through American sports and youth culture, and the later reverse-import effect back into Japan.
About the Person Who Somehow Ended Up Throwing Software Out of a Third-Floor Window
I'm Amrishkhan Sheik Abdullah, a Technical Lead and software architect based in Dubai. I build backend systems, microservices and distributed architectures for a living — which mostly means discovering that when the fifth patch doesn't fix something, the architecture may be trying to tell us something.
I write about software architecture, distributed systems, engineering decisions, AI developer tooling and, increasingly, ordinary products and behaviours that turn out to have surprisingly serious engineering hiding underneath them.
Who Saw the Connection? is my series about exactly that: true stories where somebody looked at an apparently unrelated problem and saw an idea everyone else was walking past.
Read More of My Writing
I publish longer engineering articles, architecture deep-dives and the occasional story that starts with somebody throwing watches out of a bathroom window and somehow ends up discussing your career.
Writing: amrishkhan.dev/blog
Elsewhere on the Internet
Portfolio: amrishkhan.dev
GitHub: github.com/amrishkhan05
DEV Community: dev.to/amrishkhan05
LinkedIn: linkedin.com/in/amrishkhan
If you enjoyed this one, stick around. Apparently my current research strategy is to keep staring at ordinary things until somebody's strange decision from forty years ago starts explaining software engineering.
Top comments (0)