I’ve only used this once but it worked perfectly. I was developing a function based on a regulatory document specifying how to build a calendar for regulatory reporting.

Normally you take a requirement and translate it in your mind to a convenient “shape” for coding. This is fine for most purposes. I started developing my procedure that way. Unfortunately the rules on how to handle holidays and non-working days were so complex I soon lost control. It was very difficult to see whether I was coding correctly and covering all the conditions.

I then realised it would be better to structure my code like the document, separated into the same paragraphs and with the logic identically sequenced. Given a blank sheet, I wouldn’t have structured it that way, but the programming language I was using was suitable and the code still looked reasonable.

It worked so well that the test team picked up an “error”, but it turned out that they had made a mistake. Comparison with the document showed that the code was doing the right thing. I didn’t gloat, but you can imagine how satisfying that experience is for a developer.

It isn’t a development method, or even a design pattern since it’s a method of coding a single procedure – but if you’re working from a complex, precisely defined document you might want to see whether it makes your job easier.