# The Calendar That Reached the Big Bang: A Lesson in YAGNI
> General Magic built the smartphone fifteen years before the iPhone, then watched it flop. The reason is the clearest lesson in YAGNI you will find.

*6 November 2026* · Jamie Taylor


In 1994, an engineer at a company called General Magic sat down to write a calendar. His name was Steve Perlman, and the task was about as ordinary as software gets. He wrote the calendar to run from 1904 to 2096, checked it in, and considered the job done. Four lines of code, near enough. Then one of the company's leaders wandered over. "Somebody might write a historical app," he said, "so you had better make the calendar reach back further." Perlman opened it up again and rewrote it to run from the year 1 to the future. Checked it in. Done. Then another team arrived with another objection: "why tie the thing to an arbitrary religious starting point at all? Make it go back to the beginning of astronomical time." And that is how Steve Perlman came to write a calendar function that ran from the Big Bang to the far future, on a device that did not yet exist, for users who could not yet buy it.

David Epstein, who tells this story in his book *Inside the Box*, put the cost of it in the plainest possible terms:

> If he had stuck with 1904 to 2096, it would have been four lines of code, and he could have moved on. But because they could do anything, they did, and everything always got bigger.
>
> — David Epstein, [Planet Money, NPR](https://www.npr.org/2026/06/26/nx-s1-5872785/general-magic-sony-magiclink-constraints)


This is the cleanest illustration I know of a principle that every engineer claims to believe and a surprising number quietly ignore. It is usually written as YAGNI, which stands for "You Aren't Gonna Need It." The idea is almost insultingly simple: build the thing the requirement in front of you actually calls for, and resist building for the requirement you have imagined it might one day have. Perlman's calendar is what happens when nobody in the room is willing, or able, to say that the four-line version was the finished version. The reason I keep coming back to it is that the calendar was not a strange one-off. It was the entire company, written small.

## The Most Expensive Company You've Never Heard Of


If you have not heard of General Magic, that is part of the story rather than a gap in your knowledge. In the early 1990s it set out to build what was, in every meaningful respect, the iPhone, roughly fifteen years before Apple shipped the real one. From a device in your palm you would make calls, send faxes, buy things, book travel, find your way around, and play games. None of it existed yet. At a time when I was carrying a pocket of coins around for the payphone, a small company in Silicon Valley was quietly trying to invent the lot.

And when I say the lot, I mean it without much exaggeration. Tony Fadell, who joined as employee number 29 and later went on to lead the iPod and the iPhone at Apple, described the scope of it on the *Planet Money* podcast: the operating system, the chips, the devices, the network servers and their software, the user interface, the applications, the touch screen. All of it, invented in one building. The money was there to match the ambition; the investors included Apple, AT&T, Motorola, Sony and Panasonic, and they poured many millions into the company because each of them wanted a piece of what looked like the next big thing.

The product finally arrived in the autumn of 1994 as the Sony Magic Link, and it sold for eight hundred dollars, which is a little over two thousand dollars in today's money. It shipped with a two-hundred-page manual. Fewer than three thousand units were ever sold, most of them to the friends and families of the people who built it, and within a couple of years the company that was going to change the world had become a footnote that almost nobody outside the industry remembers.

So here is the question worth sitting with, because the easy answer is wrong. General Magic had the talent, the vision, the money and the time, more of each than almost any startup before or since. It had every advantage we are taught to wish for. Why did having all of it produce one of the most expensive failures of its decade?

## The Four-Line Version Was the Right Version


Epstein's answer, after years spent researching what happens to people who have too much freedom, is that the advantages were the problem. They had so much talent, time and money that they could do anything, and so they did do anything. There was no clear customer, no specific problem they were solving, and therefore nothing to tell them what to leave out. A calendar that runs from 1904 to 2096 is a decision. A calendar that runs from the Big Bang is the absence of one.

This is the heart of YAGNI, and it is worth being precise about what the principle does and does not say. It does not say that simple means crude, or that you should build something you know to be inadequate. It says that the simplest design which fully meets the actual requirement is almost always the right one, and that sophistication should be added only when a real, present requirement forces your hand. The Magic Link did not fail because its engineers were not clever enough. It failed because they were clever in service of needs that no living customer had, on a device that, in the end, could not reliably do the one thing its name promised. The finished product never delivered on being a phone.

There is a companion argument to this one, from the architecture side, in a piece of mine on why you are not Netflix and should stop over-engineering your systems; that one is about reaching for a hyperscaler's architecture when you have neither their traffic nor their budget. This post is about the same instinct one level up, at the level of scope rather than structure: building the feature, the abstraction, the configurability that nobody has asked for, because you can imagine a future in which somebody might. The book *The Rules of Programming* makes the same case in a single discipline I try to hold myself to, which is [to delay complexity until the moment it earns its place](/blog/continual-professional-development/the-rules-of-programming-4-finding-simplicity-in-complexity/). The four-line calendar was not a smaller version of the right answer. It was the right answer, and everything after it was the bug.

## Why Good Engineers Build the Big Bang


The uncomfortable part of the General Magic story is that the people in it were not careless. They were some of the most gifted engineers of their generation, several of whom went on to build Android, eBay, LinkedIn and a good slice of early Google. If they could talk themselves into a calendar that reached the Big Bang, the rest of us are not safe either, and it is worth understanding the forces that pushed them there.

The first is wired into us. Epstein points to something psychologists call additive bias, the deep human tendency to solve problems by adding rather than taking away:

> For most of human history, the main problem was having too little, not too much. And so it's likely that we are not well equipped to even understand when to intuitively say, oh, this is too much, and to cut back.
>
> — David Epstein, [Planet Money, NPR](https://www.npr.org/2026/06/26/nx-s1-5872785/general-magic-sony-magiclink-constraints)


When you watch a planning session drift, this is the current it is drifting along. Every "what if" adds a branch, every edge case adds a guard, and almost nobody in the room instinctively argues for less. Removing the support for years before 1904 feels like taking something away from the product. Leaving it in feels like generosity. Additive bias is why the second instinct usually wins.

The second force is the absence of any constraint to push back. With no deadline, no budget ceiling and no specific customer, there was nothing to make anyone choose. Epstein's view is that the company would have done far better to stay very, very small for years, because that is precisely when you set the boundaries and stop the costs from exploding. Instead, as the trouble started, they did the opposite and hired aggressively. There is a well-worn law in software for exactly this, named after the computer scientist Frederick Brooks: adding people to a project that is already late tends to make it later still. I wrote about Brooks and the wider discipline of managing rather than merely accumulating complexity in my notes on [*The Checklist Manifesto*](/blog/continual-professional-development/the-checklist-manifesto-lessons-in-managing-complexity-for-modern-tech-teams/), and General Magic is the lesson in its purest, most expensive form.

The third force is the most human of the lot. With time and money and no customer to answer to, the engineers ended up building for each other. The audience for the work became the cleverest person in the next cubicle, and the way to impress that person is never to do less. It is to write the calendar that reaches the Big Bang and check it in with a flourish.

## Leaders Who Were Legends, and Nobody Who Was a Manager


There is a distinction running underneath all of this that I think matters enormously, and the *Planet Money* episode draws it out better than most management books. General Magic was run by legends, genuine icons of early personal computing, and the people who worked there rightly revered them. The trouble is that being a legendary programmer and being a manager are not the same job, and the company had a great deal of the former and almost none of the latter.

Epstein is precise about the gap. The leaders were icons, and so everyone listened to them; but those same icons were not equipped to set deadlines, clarify priorities, or tell a brilliant engineer that a brilliant idea was not the priority this month. They were off building the things they personally found interesting, which is what legends do, while the work that a manager exists to do simply went undone. Nobody owned the unglamorous discipline of deciding what not to build. So when Steve Perlman needed someone to say "the four-line calendar is finished, move on to something a customer will pay for," there was no such person in the building. There were only more leaders, each with another good idea.

I have written before about how readily our industry hands people a title without the substance that is supposed to sit beneath it, in [a post about software teams that are not actually engineering](/blog/the-engineer-title-when-software-teams-arent-actually-engineering/). The General Magic version is the leadership equivalent. A title on a business card, or a reputation earned writing legendary code a decade earlier, does not by itself confer the ability to hold a team to a scope. Promoting your best engineer to lead, and then assuming the leading will take care of itself, is one of the most common and costly mistakes I see. Leadership inspires people to build. Management decides what they build, and crucially what they do not. A team with the first and none of the second will build you a calendar that reaches the Big Bang every single time.

What that missing discipline actually sounds like is faintly unheroic, which is most of the reason it goes missing in the first place. Brené Brown, writing about perfectionism in [*Daring Greatly*](https://app.thestorygraph.com/books/c2ea6d65-b7be-46cc-852b-195205397e31), draws a sharp line between healthy striving and the kind of perfectionism that masquerades as it, and lands on a deceptively quiet conclusion: good enough really is good enough, and perfection is more often the enemy of done than the route to it. A manager's most valuable sentence is frequently no grander than that permission, the one Perlman was never given. This is finished. Finished was the goal. What kept reopening the calendar was not a lack of talent but the absence of anyone willing to say that thoroughness, past a certain point, is just perfectionism with a respectable job title.

## Constraints Are a Feature, Not a Punishment


If the absence of limits is what sank General Magic, the natural next question is what their presence actually does for you. The research on that is more encouraging than you might expect. Epstein's whole book is an argument that constraints are not the enemy of creativity but the engine of it, and the examples he gathers cut across fields that have nothing to do with software, which is part of why they stick.

The one the episode lingers on, and the one that has stuck with me since, is Dr. Seuss. An editor bet him that he could not write a book using no more than a short list of words a first-grader would know. Seuss took the constraint and wrote *The Cat in the Hat* from a vocabulary of around two hundred and twenty words. Then, pushed further, he wrote *Green Eggs and Ham* using just fifty. Those are not the books he would have written with unlimited freedom; they are better than the books he would have written with unlimited freedom, and they are better *because* of the limit, not in spite of it. Psychologists have a name for this, a desirable difficulty: the constraint forces you to give something up, and in working out how, you produce something you would never have reached on the open road.

Software is full of these moments if you let yourself see them. A tight deadline forces you to cut the feature that was never load-bearing. A small budget pushes you towards the boring, proven component instead of building your own. Keep the team small and the design has to stay small with it, contained enough that a single person can hold the whole thing in their head. None of these feel like gifts when you are inside them. Every one of them is the thing standing between you and a calendar that reaches the Big Bang.

## The Same Engineer, the Opposite Result


The most persuasive evidence that constraints were the missing ingredient is that one of the people from General Magic went on to prove it himself, with the same hands and a completely different result. Tony Fadell left, and a few years later turned up at Apple with an idea for a portable music player. This was March 2001, and Apple was around five hundred million dollars in debt. There was no money to throw at the problem, and Fadell is unusually clear that this saved him:

> You can have too much money. You absolutely can, because you don't have constraints to make you think hard. When you know the clock is ticking, and the account is draining, and you have to really understand what it is you're building, it focuses people.
>
> — Tony Fadell, [Planet Money, NPR](https://www.npr.org/2026/06/26/nx-s1-5872785/general-magic-sony-magiclink-constraints)


Look at what the constraints produced. He started with a customer so specific you could picture them: someone who wanted a thousand songs in their pocket. He had a hard deadline, Christmas, less than eight months out, because he knew Sony would ship something for the season and that Apple would cancel the project if it missed the window. And rather than invent everything from scratch, the way General Magic had reinvented even the technology that connects a remote to a television, he went looking for parts he could build on. He found existing processors, batteries, screens and ground-level software, and assembled them like a set of building blocks. He even tore apart a Danish cordless phone he admired to understand its scroll mechanism, which is part of how the iPod ended up with that wheel.

Same engineer. The opposite of unlimited freedom. The iPod shipped in months, and two hours after the launch Steve Jobs was already asking about the next one. Where General Magic got a single, exhausted shot across several years and then ran out of money before it could try again, Apple iterated through eighteen versions of the iPod and, eventually, into the iPhone. The constraint did not slow Fadell down. It was the only reason he got to keep going.

## What This Means for Your Team


I find that most engineering leaders nod along to all of this in the abstract and then go back to work and approve the Big Bang calendar anyway, because in the moment it never looks like over-building. It looks like being thorough, like future-proofing, like the responsible thing a senior person does. The engineer in front of you is not asking to waste six months; they are asking to handle a case that might come up, and saying no feels small.

That is exactly why the discipline has to be deliberate rather than instinctive, because instinct, as we have seen, adds. The next time someone on your team proposes building for a requirement that does not yet exist, the question is not whether the elaborate version is clever. It almost always is. The question is whether a real, present customer need has earned it yet, and whether there is anyone in the room whose job is to say "not yet" and make it stick. Finding out whether that need is real is a skill in its own right, and it was the subject of [last week's post on *The Mom Test*](/blog/continual-professional-development/the-mom-test-stop-asking-people-if-your-idea-is-good/).

Next week's post turns the same idea inward, on a Japanese way of seeing imperfection that says there is no finished version of a developer, either.

Having spent close to twenty years in and around teams of every size, from local firms to globally recognised companies, the most over-engineered systems I am called in to look at were almost never built by careless people. They were built by good engineers, each adding a locally reasonable piece of sophistication that nobody had the standing or the remit to refuse, until the whole thing became a calendar reaching back to the beginning of time on a device that still could not make a phone call. If your software has quietly grown harder to change than it used to be, and you are no longer sure how much of that complexity is essential and how much was built for a future that never arrived, [an architecture review is a sensible place to start](/schedule-consultation/). Sometimes the most valuable thing an outside pair of eyes can do is point at four lines of code and tell you that they were always enough.