In my 25-odd years in this business, I've written a lot of great programs on paper. I've developed HTML prototypes using nothing more than a good text-editor, and thrown them away dozens of times in dozens of meetings. (That's what they were for...) I've written documents, and felt the same mental processes churning through my head that I've always felt when writing source. The idea took shape in my head and poured-out onto paper, and when sometimes-serious problems inevitably showed-up all I had to use was the “strikethrough” tool.

I learnt to do it that way too, 30 years ago. But then I realised that editing on screen is far more efficient that doing it on paper, so I gave up the paper. Then I discovered that prose was horribly misinterpetable. On paper I'd often used Wernier-Orr diagrams for bits of the design, but they were hard to draw and maintain, even in an editor, so I started using a form of pseudo-code; a hybrid of several I'd studied and various languages I'd used.

After a while of that it dawned on me that if I actually used real code, instead of pseudo-code, I could mock-up the lower levels quite quickly and then get the lanaguage compiler or interpreter to verify what I'd written. It would point out inconsistancies, typos, mismatches in parameters. Stuff like that.

And that led me to making the lower levels return mocked-up, but feasible return values. Then I could actually run the upper levels very early on. Demonstrate them, Test them. Show them to clients/stake holders.

With a little more effort in adding a few sleeps or loops calculated to approximate the time taken by the as yet unwritten lower levels, I could even get a feel for what performance might be like. Measure it at a very early stage and track it as development went along. Show to the clients and get feedback on their impressions of whether it was good enough for their purposes.

Often the first cut of the higher levels would show up some inconsistancy or other and I'd throw it away and start again in the knowledge of where it had gone wrong. Invariably, the second cut was better and came together more quickly than the first.

After a few years they invented a name for this process. It's called RAD.