Category: PW Use Cases

Computer programming and book writing are similar. Time is spent making something that is soft, an art, without physical form like a weldment or statue.

In the art of computer programming, the industrial revolution’s ideas of separations of concerns are applied by the successful companies. Tasks are split into minor goals that can be farmed out to multiple, disparate people. They make code. After, tests can be run against the libraries they develop to check them against the contract specifications and see if they work.

PW lets similar ideas happen when writing a work of fiction. We make contracts and let the laborer perform them; we check their work and see how close they came to the idea we asked for.

My new authoring system Parametric Writing tags Sentences with metadata, with Rules and Briefs, allowing a book to be shelled out and drafted, then filled in and improved, based on specific asks and goals.

Programmers call this a functional description or a specification.

At work I dabble in mechanical designs. Machines and systems to accomplish small tasks, like convey product, install o-rings or weld tubes.

We have a layered system that allows people to specialize. Our CNC machinists take a part blueprint and make that part, using just what appears on the blueprint. They don’t double-check the other components to see if they fit or if the product going through, with its inherit variations, will get stuck.

My engineering design might cost ten dollars, and making the machine might cost one hundred. If we need to change the machine after, the costs expound. We try to make everything work the first try. The most embarrassing moments are when I make two parts that bolt together, but the bolt holes do not line up.

Billy and I check for that using design rules on the computer. We have intricate solid models and designs that can be verified automatically using rules that check for fitment and tolerancing. Our boss can see how many of the checks we ran.

Nothing is worse than having an interference in your machine. You design two separate assemblies full of parts, and one of the parts moves into another while the machine runs. It is an error that can be seen blatantly on the computer screen, and yet, you gave the poor machinist the prints and he made the parts; the assemblers put them together and we tried to run the motion.

More engineering- more verification- on the front end helps. More ways to add details and add information into the computer let others review the solution for potential issues, and open the path for Artificial Intelligence checks.

I can’t imagine drawing parts on paper using a pencil and expecting them to ever work together, but in the 50’s people did that.

And that is how I see authors now-a-days. I don’t want to design like someone in the fifties. I want to leverage the computer’s infinite memory and let my thoughts flow, store them, let us review the later.

Parametric Writing is my answer to this call.

I wrote a book. I mean, after all, I created the writing system Parametric Writing, so I had to use it on something. You can get the fulltext in printing format from my blog post over on my personal website: Post with PDF of Understructure

Of course, that is a flat, raw text document. It is about 250 pages in trade size.

What you really want to look at is the Parametric Writing editor view of my book. You’ll see the Briefs and Rules that I defined, and how they link into and throughout the book. Click here to open the editor: PW Understructure Story