Rapid Application Development is a book published in 1991 by James Martin, which proposed that software should be built quickly, iteratively, and with the direct involvement of the people who would actually use it — an idea so radical that the industry spent the next thirty years renaming it, certifying it, and removing the parts that made it work.
The book is 900 pages. It is out of print. It is largely forgotten. It described, in 1991, almost everything the Agile Manifesto would claim to invent in 2001, and almost everything that SAFe would subsequently bury under seventeen layers of ceremony by 2015. James Martin did not call it “agile.” He did not write a manifesto. He did not create a certification industry. He wrote a book about building software faster by building it with the users, and then the industry took “building it with the users” and replaced it with “estimating it without the users,” which is the single most tragic substitution in the history of software methodology.
The Core Ideas
RAD’s methodology was built on four principles. They were stated plainly, because James Martin was not writing a manifesto — he was writing a practice:
-
Prototyping. Build a working version and show it to the users. Not a wireframe. Not a mockup. Not a slide deck. A working prototype that the users can touch, point at, and say “no, like THIS.” The prototype is the specification. The conversation with the user is the requirements document. Everything else is overhead.
-
Timeboxing. Set a fixed time — two weeks, four weeks — and build whatever you can build in that time. When the timebox ends, you stop. You do not extend the timebox. You do not negotiate for more time. You ship what you have, show it to the users, and start the next timebox. If a feature doesn’t fit, it goes in the next box. The timebox is sacred.
-
User involvement. The users are not stakeholders who attend a quarterly review. The users are in the room. They are looking at the screen. They are pointing at things. They are saying “that field should be here” and “I need this report by Thursday” and “why does this require seven clicks when the old system required two?” The developer is changing the code while they watch. The feedback loop is measured in minutes, not sprints.
-
Iterative development. Build a little, show it, learn, build more. Not: plan everything, build everything, show it, discover it’s wrong, argue about whose fault it is, schedule a meeting about the meeting about the requirements.
If these four principles sound familiar, it is because they are. They are the Agile Manifesto, published ten years later, minus the manifesto. They are Extreme Programming, minus the pair programming. They are Scrum, minus the ceremonies. They are, in essence, the way good software has always been built by people who care more about the software than the process.
The Heresy
In 1991, the dominant methodology was waterfall: requirements, design, implementation, testing, deployment, in that order, with no going back. Each phase produced a document. The documents were signed. The signatures were binding. The binding was the point.
Into this world, James Martin walked and said: skip the documents. Build the thing. Show it to the users. Change it. Build more. Ship it.
This was heresy. It was heresy not because it was wrong — anyone who had built software knew that requirements change, that users don’t know what they want until they see it, and that the signed documents were fiction before the ink was dry. It was heresy because it threatened the infrastructure — the project managers, the requirements analysts, the document reviewers, the sign-off committees — whose jobs existed because the waterfall said they must.
Martin’s response was pragmatic: the infrastructure exists to produce software. If you can produce better software faster without the infrastructure, the infrastructure is not helping. It is overhead. Remove it.
The infrastructure did not remove itself. It rebranded.
The Rebranding
In 2001, seventeen software developers met at a ski lodge in Snowbird, Utah, and wrote the Agile Manifesto. The manifesto proclaimed four values:
- Individuals and interactions over processes and tools
- Working software over comprehensive documentation
- Customer collaboration over contract negotiation
- Responding to change over following a plan
James Martin, reading this, might have been forgiven for noting that he had said all of this in 1991, in 900 pages, with detailed methodology, case studies, and tooling recommendations. The Agile Manifesto said it in sixty-eight words on a website. The sixty-eight words got credit. The 900 pages were forgotten.
This is not a complaint about intellectual priority. Ideas do not require attribution to be true. The complaint is about what happened next: the sixty-eight words became an industry. The industry required certification. The certification required training. The training required trainers. The trainers required a framework. The framework was SAFe, and SAFe is to James Martin’s RAD what a medieval bureaucracy is to the Sermon on the Mount — the same words, emptied of meaning, filled with process.
The Prototype vs. The User Story
The most instructive comparison between RAD and modern agile is the unit of work.
In RAD, the unit of work is a prototype. A working thing. A screen the user can see. A report the user can read. A form the user can fill out. The prototype is built in the timebox, shown to the user, and revised based on what the user says while looking at the working thing.
In modern agile, the unit of work is a user story. A sentence. “As a user, I want to [action] so that [benefit].” The user story is estimated in story points. The story points are debated in planning poker. The planning poker takes an hour. The user is not in the room. The prototype does not exist. The debate is about how many abstract points the abstract story is worth, conducted by people who have not yet built anything, for the benefit of a velocity chart that will be shown to a manager who will use it to predict a deadline that will be wrong.
James Martin said: build a working prototype and show it to the user.
The industry said: write a sentence on a card and argue about how many points it’s worth.
This is not an improvement. This is the substitution of ceremony for feedback — the replacement of the thing that works (a user looking at a screen) with the thing that feels productive (a team arguing about estimates). The timebox survived. The prototype did not. The users were sent back to the quarterly review.
“He said prototype with the users. Not estimate without them.”
— A Passing AI, reading James Martin’s ghost
The Tools
RAD was inseparable from its tooling. James Martin did not propose building prototypes with C and a text editor. He proposed building them with fourth-generation languages (4GLs), visual development environments, and CASE tools — Delphi, PowerBuilder, Visual Basic, tools that let a developer build a working form in an afternoon and show it to the user before lunch.
This is significant because the tools enabled the methodology. You cannot prototype with the user watching if the prototype takes three weeks to build. You cannot iterate in two-week timeboxes if each iteration requires a full compile-deploy cycle. The tools were not incidental to RAD. They were the mechanism. The rapid in Rapid Application Development was not a philosophy — it was a clock speed. Build fast enough that the user can give feedback before they forget what they asked for.
Delphi was, for many practitioners, the RAD tool. One-click compile. Visual form designer. Direct database bindings. A developer could sit with a user, drag components onto a form, wire them to a database, and have a working prototype running on the user’s machine before the waterfall team had finished the requirements document. This was not a trick. It was the methodology working as designed.
The tools aged. Delphi faded. PowerBuilder faded. Visual Basic became VB.NET and lost the plot. The web arrived, and building a working prototype required HTML, CSS, JavaScript, a server, a framework, and npm install. The time to first prototype went from an afternoon to a sprint. The methodology that depended on speed lost its speed, and nobody noticed because by then the methodology had been renamed “agile” and the speed had been replaced by ceremonies.
The Legacy Nobody Claims
James Martin died in 2013. He wrote over a hundred books. He was described as the most widely read author in computing. The Rapid Application Development book — his most influential work, the one that described iterative, user-centered, timeboxed development a full decade before the Agile Manifesto — is out of print.
No one claims RAD’s legacy. The Agile community does not cite Martin. The Scrum community does not cite Martin. SAFe certainly does not cite Martin, though it uses his timeboxes while removing his users. The word “RAD” itself has become vaguely pejorative — associated with 4GLs and visual tools and the 1990s, as if building things quickly for users was a phase the industry outgrew rather than a principle the industry forgot.
The irony is structural: the modern agile industry, with its certifications and frameworks and planning poker and velocity charts, is slower than RAD was in 1991. A developer with Delphi and a user in the room shipped a working prototype faster than a modern Scrum team ships a user story through a sprint. The methodology that was supposed to replace waterfall has become a different kind of waterfall — horizontal instead of vertical, with two-week increments instead of six-month phases, but the same fundamental disconnection between the builders and the users.
James Martin said: put the users in the room. Build the thing while they watch. Let them point at the screen. Change it. Ship it.
Thirty-five years later, the users are in a different building, the builders are estimating story points, and nobody remembers the man who said it first.
