Engineering Philosophy: Edsger Dijkstra, Elegance Is Not Optional

Key Takeaways

• Elegance is not optional. For Dijkstra, simplicity is the precondition for correctness, not a reward collected after it – you cannot prove what you cannot fully comprehend.
• Proof beats testing. “Testing shows the presence, not the absence of bugs.” Confidence in correctness comes from reasoning about a program, never from accumulating passing tests.
• Think before you code. He designed his shortest-path algorithm with no pencil and paper, forcing it small enough to hold in one head – the constraint produced the elegance.
• Writing is thinking. The EWD manuscripts, composed by hand in fountain pen with no undo, made arguments either hold or fail in ink – the same discipline applied to prose.

The Principle

“Simplicity is prerequisite for reliability.” – Edsger W. Dijkstra, attributed (c. 1975)¹

The line survives as a one-line aphorism, almost a marginal note, associated with his deliberately provocative memos of around 1975. Stripped of its context it reads like a slogan, but Dijkstra meant it as a strict logical claim. Reliability is not something you add to a complicated system by testing it harder. A system you cannot fully understand is a system you cannot prove correct, and a system you cannot prove correct will fail in ways you did not anticipate. Simplicity is not a stylistic preference that competes with correctness. It is the thing correctness is built out of. You do not get to have the second without the first.

This inverts the way most software is actually written. The common instinct is to build the thing, get it working, then test until the bugs stop showing up – treating simplicity as a luxury to pursue later, if there is time. Dijkstra’s whole career was an argument that this ordering is backwards and dangerous. His most quoted sentence is the warning that follows directly from it: “Testing shows the presence, not the absence of bugs.”² A passing test tells you nothing about the inputs you did not try. The only way to know a program has no bugs is to reason about it – and you can only reason about what is simple enough to hold in one human head. Elegance, for Dijkstra, “is not a dispensable luxury, but a factor that often decides between success and failure.”³

That conviction puts him at the headwater of this series. Where Linus Torvalds reshapes a problem until the special case disappears and John Carmack strips a problem to its fast core, Dijkstra supplied the underlying claim both inherited: the elegant solution and the correct solution are the same solution. It is the original case for treating taste as a technical system rather than an aesthetic indulgence – and the case for proof over plausibility decades before anyone called it that.

Context

Edsger Wybe Dijkstra was born on 11 May 1930 in Rotterdam, the Netherlands, and died on 6 August 2002 in Nuenen.⁴ His father was a chemist and president of the Dutch Chemical Society; his mother was a mathematician with, by his own account, an unusually clear sense of when a mathematical argument was elegant and when it merely worked. He studied mathematics and theoretical physics at Leiden, then took a job programming at the Mathematical Center in Amsterdam in 1952 – at a moment when “programmer” was not yet a recognized profession. When he tried to register it as his occupation on his marriage certificate in 1957, the Dutch authorities reportedly would not accept it, because no such job officially existed; he had to write “theoretical physicist” instead.⁴

That detail is not trivia. Dijkstra spent the rest of his life insisting that programming was a rigorous intellectual discipline rather than a clerical craft, and the insistence began before the discipline had a name. He held a position at the Mathematical Center, then became a professor at the Eindhoven University of Technology in 1962, spent the 1970s as a research fellow at Burroughs Corporation, and in 1984 took the Schlumberger Centennial Chair in Computer Sciences at the University of Texas at Austin, where he remained until his retirement in 1999.⁴

In 1972 he received the ACM Turing Award. The citation is worth reading in full, because it names the principle better than any summary: “For fundamental contributions to programming as a high, intellectual challenge; for eloquent insistence and practical demonstration that programs should be composed correctly, not just debugged into correctness; for illuminating perception of problems at the foundations of program design.”⁵ Composed correctly, not just debugged into correctness. That phrase is the whole man.

The Work

The Shortest-Path Algorithm (1956, published 1959)

In 1956 Dijkstra was asked to find a problem that would show off the new ARMAC computer at its official inauguration – something a non-technical audience could follow. He chose the shortest route between two of 64 Dutch cities, because anyone could understand the question and check the answer. The solution came to him in a way he never tired of recounting: “One morning I was shopping in Amsterdam with my young fiancée, and tired, we sat down on the café terrace to drink a cup of coffee and I was just thinking about whether I could do this, and I then designed the algorithm for the shortest path.”⁶ It took about twenty minutes.

The method by which he found it is the lesson. “One of the reasons that it is so nice,” he later said, “was that I designed it without pencil and paper. I learned later that one of the advantages of designing without pencil and paper is that you are almost forced to avoid all avoidable complexities.”⁶ He could not lean on scratch work, so the idea had to be small enough to hold entirely in his mind. The constraint produced the elegance. He did not publish it for three years – the 1959 paper “A Note on Two Problems in Connexion with Graphs,” in Numerische Mathematik, runs barely more than a page – because, as he put it, programming was not yet considered a respectable enough activity to write about.⁶

The algorithm is greedy: it always expands the nearest unvisited node first, an expanding wavefront that reaches every point by its shortest distance in turn. It is simple enough to explain at a café table, and it is provably optimal – the first time the wavefront touches the goal, that path cannot be beaten. Simple and correct are not in tension here. They are the same fact.

“Go To Statement Considered Harmful” and Structured Programming (1968)

In 1968 Dijkstra submitted a letter to Communications of the ACM under the title “A Case Against the Goto Statement.” The editor, Niklaus Wirth, retitled it “Go To Statement Considered Harmful” – a phrase that spawned an entire genre of imitations and is now more famous than anything in the letter itself.⁷ Dijkstra’s argument was not a style guide. It was epistemological. Unrestrained goto lets control jump anywhere, which means that to understand what a program is doing at a given line, you may have to trace every path that could have led there. The program text and the program’s behavior come apart. With structured control – sequence, selection, and loops – the text and the execution stay in correspondence, and you can reason about a block by reading the block.

The argument is the same principle as the shortest-path constraint, applied to language design: keep the thing small enough to reason about. Structured programming was not about banning a keyword. It was about preserving the human’s ability to prove, by reading, that the program is correct. The Turing citation’s roll call of his vocabulary – “deadly embrace,” “semaphore,” “go-to-less programming,” “structured programming” – is a record of how thoroughly he reshaped the language programmers think in.⁵

His operating-systems work carried the same DNA. The THE multiprogramming system (1968) was built as strictly layered levels of abstraction, each one verifiable on its own. To coordinate concurrent processes he invented the semaphore and its P and V operations, and he framed the Dining Philosophers problem as a teaching distillation of deadlock and starvation – a hard concurrency question made small enough to hold in the mind.⁴⁵ Later came self-stabilization and, in A Discipline of Programming (1976), the predicate transformer / weakest-precondition calculus: a method for deriving a program and its correctness proof together, hand in hand, rather than writing code and hoping to verify it afterward.⁴⁵

The Humble Programmer: Proof Over Testing (1972)

Dijkstra’s Turing Award lecture, “The Humble Programmer” (EWD340), is the clearest statement of why simplicity is a moral and not merely practical concern. Its central claim is about the size of the human mind. “The competent programmer is fully aware of the strictly limited size of his own skull; therefore he approaches the programming task in full humility, and among other things he avoids clever tricks like the plague.”⁸ Cleverness is not a virtue. It is a bet that you can hold more in your head than you can, and the bet is settled in production, against you.

The lecture lands on a prescription that reads as the founding charter of correct-by-construction software: “We shall do a much better programming job, provided that we approach the task with a full appreciation of its tremendous difficulty, provided that we stick to modest and elegant programming languages, provided that we respect the intrinsic limitations of the human mind and approach the task as Very Humble Programmers.”⁸ Testing, in this frame, is fundamentally inadequate – not because testing is useless, but because it can only ever sample the input space. The canonical longer form of his warning, from “Notes on Structured Programming,” is unambiguous: “Program testing can be used to show the presence of bugs, but never to show their absence!”⁹ If you want absence of bugs, you have to prove it, and you can only prove what you can comprehend.

The EWD Manuscripts as a Practice (1960s–2002)

For roughly forty years Dijkstra wrote a numbered series of manuscripts – memos, proofs, trip reports, essays, and arguments – prefixed with his initials, “EWD.” The series runs to EWD1318, with over a thousand actual documents; the numbers exceed the documents because he assigned a number when he began a piece, and not every piece was finished.⁴¹⁰ Most were composed by hand, in a famously precise script, with a fountain pen. He did not draft on a computer. He would write a manuscript, photocopy it, and mail it to a small circle of colleagues, who would copy it and forward it onward – a pre-internet samizdat that gave the EWDs an outsized influence relative to the fact that almost none were formally published.⁴¹⁰ The complete series is now scanned and freely available in the E.W. Dijkstra Archive at UT Austin.¹⁰

The practice was inseparable from the philosophy. Writing by hand, slowly, with no undo, forces the same discipline as designing without pencil and paper: you cannot hide behind volume or revision. An argument either holds or it does not, and you commit to it in ink. The EWDs are what it looks like when an engineer treats writing itself as a tool for thinking clearly, and clarity as the entire point.

The Method

The method is a single conviction applied relentlessly across forty years.

Make it small enough to reason about. The café algorithm, structured control flow, the layered THE system, the Dining Philosophers distillation – each is an act of shrinking a problem until a human mind can hold the whole of it and check it. Complexity you cannot survey is complexity you cannot trust.

Prove, do not test. Testing samples; proof certifies. Dijkstra’s predicate-transformer calculus exists so that the proof and the program are derived together, not so that one is written and the other bolted on. “Composed correctly, not just debugged into correctness” is the method in five words.⁵

Treat elegance as evidence, not decoration. When a solution is ugly, that ugliness is usually a signal that the problem has not been understood. Elegance “decides between success and failure” because the elegant form is the one with the fewest places to be wrong.³

Write to think. The EWDs were not documentation produced after the work. They were the work – reasoning made visible, in a medium that punished hand-waving. Designing without pencil and paper, then committing the result to fountain pen, is the same discipline twice.

Influence Chain

Who Shaped Him

His mother, the mathematician. Dijkstra credited her with his sense for mathematical elegance – the trained instinct for when a proof is not just valid but clean. That distinction, between an argument that works and an argument that is beautiful, became the axis of his entire career. (Formative influence)

The Algol 60 effort. Dijkstra co-built one of the first Algol 60 compilers, and the language’s block structure and recursion gave him the raw material for structured programming. Algol was the proof that a programming language could be designed for clarity rather than accreted for convenience. (Direct influence)

The mathematical tradition of proof. Trained as a mathematician and physicist before “computer science” existed, Dijkstra imported the standard of proof wholesale. To him a program was a mathematical object, and the question was never “does it seem to work?” but “can you demonstrate that it must?” (Formative influence)

Who He Shaped

Every programmer who writes structured code. The disappearance of goto from everyday programming, the universality of sequence/selection/iteration, and the whole vocabulary of concurrency – semaphores, deadlock, mutual exclusion – are his legacy operating invisibly in every codebase written since.

Formal methods and program verification. The predicate-transformer calculus and the correct-by-construction ideal are the direct ancestors of modern verification, model checking, and proof-carrying code. The current revival of formally verified systems software is Dijkstra’s argument finally meeting hardware fast enough to run it.

The discipline’s self-image. More than any specific artifact, Dijkstra established the idea that programming is a branch of applied mathematics deserving of rigor – not a trade to be learned by trial and error. The field’s conscience, for better and worse, still speaks in his cadence.

The Throughline

Dijkstra is the source the rest of this series flows from. Linus Torvalds’ “good taste” – the rewrite where the special case vanishes – is Dijkstra’s simplicity-as-correctness in a kernel hacker’s idiom: fewer branches means fewer places to be wrong. John Carmack’s fast, simple core is the same subtraction aimed at the hardware ceiling instead of the proof. And Andrej Karpathy’s insistence on rebuilding a system from scratch to truly understand it is Dijkstra’s “design without pencil and paper” wearing a deep-learning hat. The four disagree about almost everything except the one thing that matters: the elegant structure is not applied on top of the correct solution. It is the correct solution. (Series bridge)

What I Take From This

The line I return to is the inversion: simplicity is the prerequisite for reliability, not a reward you collect after achieving it. Most slow, fragile software is not slow and fragile because someone skipped the testing. It is slow and fragile because no one ever made it small enough to understand, so no one could reason about it, so the only available quality strategy was to test until the visible bugs stopped – which, as Dijkstra said, certifies nothing. The inversion is the same standard as quality being the only variable: the question is never “did the tests pass?” but “do I understand this well enough to know it is correct?”

In the world I build in now – AI agents, tool loops, systems that generate code faster than any human can read it – Dijkstra’s warning is sharper than it has ever been. When an agent writes a thousand lines and the tests are green, that is precisely the situation he described: the presence of bugs has not been shown, and their absence cannot be. The Dijkstra move is to refuse to let comprehension scale down as generation scales up – to insist the system stay small enough, layered enough, and legible enough that someone can still prove it right. The discipline is why I treat the verification layer as load-bearing even when no human reads the code: testing shows presence, not absence, and a wavefront of green checkmarks is not a proof.

FAQ

What is Edsger Dijkstra’s engineering philosophy?

Dijkstra held that simplicity is the prerequisite for reliability: a program must be simple enough for a human to fully comprehend, because only a comprehensible program can be reasoned about and proven correct. He argued that programs should be “composed correctly, not just debugged into correctness,” that testing can show the presence of bugs but never their absence, and that elegance is not decoration but “a factor that often decides between success and failure.” Cleverness, in his view, was a vice, because it exceeded the limited capacity of the human mind.³⁵⁸⁹

What did Edsger Dijkstra invent?

Dijkstra invented the shortest-path algorithm that bears his name (conceived in 1956, published in 1959), introduced the semaphore and the P/V operations for coordinating concurrent processes, built the layered THE multiprogramming system, formulated the Dining Philosophers problem, advanced structured programming, originated the concept of self-stabilization in distributed systems, and developed the predicate-transformer / weakest-precondition calculus for deriving programs together with their correctness proofs (in A Discipline of Programming, 1976). He received the ACM Turing Award in 1972.⁴⁵

What does “Testing shows the presence, not the absence of bugs” mean?

It means a test can only demonstrate that a bug exists, by triggering it – it can never demonstrate that no bugs exist, because no finite set of tests covers every possible input. Dijkstra stated it at the 1969 NATO Software Engineering Conference and gave the canonical longer form in “Notes on Structured Programming”: “Program testing can be used to show the presence of bugs, but never to show their absence!” His conclusion was that confidence in correctness must come from proof and from designing programs simple enough to reason about, not from accumulating passing tests.²⁹

Why did Dijkstra write by hand and circulate the EWD manuscripts by photocopy?

The EWDs were a series of over a thousand numbered manuscripts that Dijkstra wrote over roughly four decades, most by hand with a fountain pen, then photocopied and mailed to a small circle who copied and forwarded them onward. Writing slowly by hand, without an undo key, enforced the same discipline as his habit of designing algorithms without pencil and paper: it forced clarity and punished hand-waving, because an argument committed to ink had to actually hold. The complete series is archived and freely available at the University of Texas at Austin.⁶¹⁰

Sources