This section does not deal with how to work your document assembly project to maximum efficiency. What it does deal with are all the bits and pieces, approaches and thought processes that are necessary to start looking at your project in a more thorough and systematic manner. Think of this as the "How To Think Document Assembly" crash course.

The reason for this section is simple: there are many processes and design steps involved in any programming. When a programmer sits down to write something (music blaring, coffee in hand, chocolate bars in fridge - geek programmer staples!), they have a solid background in these concepts and design steps. These are the concepts and steps that are very rarely ever written out. Why? Because they are taken for granted by the programming community at large.

However, when it comes to document assembly, many developers do not plan.

Why? At the risk of making an inaccurate blanket statement, many document assembly developers have no prior programming experience, or perhaps have a macro language under their belt. I was one of the latter and I had to learn all this stuff the hard way. If you've never designed a flow chart, have no idea what "boolean" means or get a mental blank at the phrase "object oriented", then you are most likely like I was - clueless about "real" programming.

The problem comes from two sources:

• The "type" of people who are typically asked to take on document assembly work - usually its a secretary or paralegal. Why? Becuase they "do documents". The reality is that you aren't using a word processor to produce documents, you are using programming and code to do it. Regardless, the people chosen are generally not IT people and have no coding/programming/designing skills.
• Marketing - document assembly is marketed as a "2 days training and you are good to go!" type product. In fact, the training offered by many companies will in fact reinforce poor programming techniques, quite often by trainers who have never understood the basics of programming either.
  

The training will most likely run something like this:

• Brief introduction to your product (lets say HotDocs) showing libraries, templates and component files
• Show the different variable types, and the options in creating them
• Open up a simple template or document and show how to use the HotDocs toolbar
• Highlight some text and replace it with a variable, put in an IF statement, put some options in a multiple choice variable and the like
• Rinse and repeat until the document is "fully coded"
• Put all variables on a dialog, perhaps even some scripting
• Assemble the document and marvel at document assembly

This is exactly the approach I am advocating against. There is no planning here. No forethought. In their defence, it is impossible to provide 2 days training that will cover how to plan and design document assembly, variable naming structures and other critical steps as well as covering how to use HotDocs. But the problem remains - the training you will invariably be provided with is poor and will not stand you in good stead.

Counter-Intuitive Development

Many developers of document assembly I have spoken with, worked with and received systems from have one thing in common: they don't plan. They pick up document #1 and start coding, just as they were trained. If they are very knowledgeable about the area of law they are programming, and have been working with HotDocs for quite some time, things turn out ok. If not, things get difficult.

The method for development that Seth Rowland and I have worked with for about 7 years has slowly evolved over that time. Our approach to document assembly will appear counter intuitive, as if we are putting the cart before the donkey. I can assure you that it is in fact the fastest way to work a document assembly system from start to finish, without having to re-write or re-develop code. And the best news? You can apply this methodology while knowing exactly nothing about the area of law you are programming.

Our system for development achieves quite a few ends, and avoids some unpleasant occurrences in document assembly development:

• Ensure that every part of the system is documented and annotated
• Create a searchable & filterable "database" that will allow us in a couple of clicks to look at all variables, all variables on a dialog, all variables of a single type and the like
• Allow for the marking of all conditions & rules under which a variable or dialog becomes active & visible to the user
• Creates a blueprint for the entire system, allowing clients to make updates and amendments to their own system without consulting costs
• Write formulas for automatically creating variables markers, IF statements etc...
• Provide a common platform for analysis of existing code drafted by another entity
• Allows us to co-operatively work on projects, without spending hours digging through the other person's programming - we just look at the spreadsheet and the code is apparent at a glance
• Only ever re-write code if a client changes their mind after the system is delivered

The system is very easy and straight forward, but can be hard to follow because its counter intuitive to many people. The maxim behind our system is simple:

You cannot program any system until you are aware of every result that system will need to produce

To us, that means that until you've reviewed every document in a system, and catered to every result that will need to be produced, you shouldn't program a single keystroke - plan it out in minute detail first, then program the system when all is designed! Writing code, then expanding on it, re-writing it (known as re-factoring), patching it and re-doing it - this is what programmers and designers hate, because it wastes so much time. Learn to plan then code - it will save you time, money and headache.

Moving Forward

The rest of this section outlines the development process along these lines. In writing this procedure, I have used a "high end system" system approach. This means that the process I'm outlining is a fairly complete process of how to build a complex system from start to finish. The reason for this is that the process will cover most of the issues you will have to deal with in a document assembly project, no matter how complex or simple your goals are. As with any project I design, the goal is to eliminate (or at least, minimize) post assembly editing. When the document pops out, it is done: that's the goal.

The topics covered are:

Approach to Development

• Document assembly development - what works, what doesn't and why
• HotDocs specifically: shared or single component file(s)?
• Preparing for work
• Using Excel as a tracking tool to ensure proactive coding, consistency and a systematic approach to HotDocs development
• Naming schema concept

Raw Materials

• Get the raw materials together
• Consulting with staff (its their system, not yours!)

Designing The System

* From this point forward, the articles deal with in-house development of document assembly, not outsourcing

• Preparing to create a master for each template
• Amalgamate each set of related documents into the template master

Programming the System

• Time to 'Program' - its Almost Clerical Now