PDL/81 Principles

The development of PDL was guided by three principles. Today these are widely accepted as standard practice in developing reliable and efficient software.

• Design your software before coding.
• Write your design in a form your customers can read.
• Your customer will understand English better than diagrams.

Design first, code second

The design process is the creative, and most crucial part of the software developer's role.

It is a three-stage process. First, you must understand and absorb the problem the software needs to address. Second, create the ideas which solve the problem. Third, refine them until you can be highly confident that you have a complete solution.

Along the way, however, the design ideas need to be expressed and documented. In this, the designer faces similar problems to those of a foreign language translator, needing to make sure the quality of the original design idea is not lost when expressed in a new language.

A language is needed in which design ideas can be expressed easily but with complete accuracy. And, it needs to be just as suited to early design sketches as to finished, complex designs.

If a programming language is used, there is an immediate handicap because its specifics — only needed when communicating with a machine — quickly overshadow the design ideas. The result is an ill-conceived program which, at best, solves only part of the original problem.

PDL avoids this predicament by using a design language, not a programming language. It recognizes that designing is a creative process, while coding is a more mechanical one, and draws a clear distinction between the two.

Using PDL, a complete, considered, and printed design is produced before any code is written.

Write in a form your customer can read

Software design exists to solve customers' problems.

Since these problems are often particular to each customer, it follows that they are the best judges of whether a design will actually work. But they can only do so it is is written in a form they can understand.

This cuts both ways. If the customer can read the design, the designer's grasp of the problem can be easily assessed, as can the accuracy of the specification of the problem.

This is why a design written in PDL is presented in a form that is clear and uncomplicated. Even people with no programming experience can understand it. Customers are able, and encouraged, to iron-out problems and make improvements at a stage when it is still economical to do so.

A customer isn't necessarily the party paying the bill. It could be the manager who set the task, or even the software developer with a personal design goal to be achieved. In the broadest sense a customer can be anyone who knows the problem and has an interest in seeing it solved.

PDL lets anyone read a design. The more people who read it, the more likely it is to fully satisfy all their needs.

Words speak louder than pictures

Up to a point, diagrams can play a useful role in software development. At the higher level of the process, their many shapes and forms can communicate the fundamentals of a design and the broad relationships between the various parts.

As the volume of detail increases, however, the usefulness of diagrams becomes questionable. They become hard to read, unwieldy to handle and expensive to maintain. They also have the dangerous tendency to highlight all that is good and present in the design, while actually obscuring what's wrong or missing.

The answer lies in the most basic, and yet most expansive, information carrier we know: plain English. Our experience and understanding of English is far greater than that of diagrams.

With PDL, the designer has two powerful tools: the richness and familiarity of English, and the structure and precision found in a programming language. The result is unambiguous English — and total comprehension all around.

---

CFG Home Page   |   PDL/81 Home Page   |   Start of PDL/81 Intro   |   Previous   |   Next

Copyright © 1991 Caine, Farber & Gordon, Inc.