DDS Approach

When I am retained to design a system, there are only 2 things that drive my decisions: your return on investment ("ROI") and your ability to continue to use the system for as long as possible. I see little benefit in spending thousands of dollars on a system that will not receive enough through put to return your investment in a short period of time. Similarly, I don't see any point to using a document assembly program if you aren't going to embed your logic and decision processes into it.  That's just my personal take on the technology.

I don't develop systems that require my intervention to update routine details, such as a letter or fax, or staff list either.  Any common use items (staff, common correspondence, parties and players, etc) are centralised to make it easy and simple to make updates and amendments.  My aim is to provide you with a system that you can maintain with minimal (if any) assistance and that will continue to produce ROI.  While this generally costs a little more up front, the approach saves thousands of dollars in maintenance and your time within a short time frame.  Much like any software investment, initial purchase isn't the 'real cost' - ongoing support, maintenance and upgrades are.

In my opinion, a well designed and programmed document assembly system should generate 100% ROI within a 3-6 month period. The exception to this rules are systems that are designed to be very simple, and are undertaken purely as a quality control mechanism. Typically, there is little profit in these systems, as a client is not seeking profit, they are seeking to have all their documents produced with a consistent look and feel.

All my systems come with the original "blueprint", which is a filterable, sortable, searchable spreadsheet of all variables, dialogs and other programming "pieces" in your system. This blue print is designed and finalised before I code a single thing in HotDocs - I don't believe you can build a system well until you've mapped out everything it needs to do first.  So you need never be concerned about whether our design and structure will leave you "beholden" to me. I use a structured naming convention to openly write code so that it is as readable and logical as possible. You will have the complete blueprint for any system I produce, so that with a little training, you can maintain your own system should you require, or hand it to another HotDocs developer.

I just dont believe in coding practices that are unclear or require a "cipher decoder" to read them.  I believe that any custom-built software should include some kind of road-map as part of the deliverable, as I have been the "receiving consultant" who has to pick up a system with zero documentation.  When this happens, it costs a large number of hours before I can even start work.  Its not a good result for the client.

Programming Approach

There are four major items that I believe set my works apart from the works of most "document assembly developers" I have seen:

• When a system is designed, it designed as an 'entire piece'. A debt recovery library may have 150 templates in it, and every single template draws on the same code base. In HotDocs, this is known as "pointed" or "master" component files.  It is a little trickier initially, but the alternative is using "single" component files - where every template has its own individual code base.  Much like software purchasing, the largest cost is not in your initial outlay, but rather, in the ongoing support, maintenance and improvement of your system.  The first time you ever have to update 50+ (or 100+) component files because they are all individual and you want a staff change (or handle parties differently, or any other data that relates to most templates in a system), you will immediately see the benefit to this approach.
  
• I program in a very structured and logical way - all of my component names are formulas that self sort, self group and self identify. All of my variable names are formed with:
  
  • prefixes that identify a 'data group' - all variables related to Plaintiffs start with "PLFS", so they will all line up together conveniently (HotDocs alpha sorts your variable lists)
  • suffixes that identify a variable 'type' - all single-line text variables end with TE, but multi-line text variables end with MEM.
    
  • the 'middle' of the variable is actually 'the real name', usually in "reverse english".  "Plaintiff First Name" and "Plaintiff Last Name" don't help you when your variable list is sorted by alpha - if you have 20 or so Plaintiff variables (which you commonly would), the first and last parts of the name are nowhere near each other!  But "PLFS Name First TE", "PLFS Name Middle TE", "PLFS Name Last TE" and "PLFS Name Company TE" certainly do help - reverse english means that everything that is related stays together in your development environment.
    
• Approximately 20% of my work is actually programming document assembly. The other 80% is consulting, planning, structuring and client care on delivery. This benefits my clients as I  provide them with the blueprint with which their system was designed. Every variable, every dialog, every condition and every rule is documented plainly, grouped by usage and able to be sorted and filtered. You can see anything in your system at a glance with a few clicks at most.
• Because of my programming and planning approach, I am very rarely re-writing code. If you select the first document in a stack and start programming it, you will encounter issues later, because you are programming a system before you are aware of every result the system needs to produce. I am not prescient, so I plan ahead before I program a system. This means no extra hours expended backtracking my own work due to 'premature programming'.

As an odd side comment, english is the "odd one out" when it comes to languages generally.  In most other languages, "I love you" is "You, I love" - you state the noun you're talking about ("you"), then attach the verb/adjective ("love").  My coding approach is similar; instead of "First Name" its "Name, First".  Unfortunately, it is counter-intuitive initially to a native-english speaker.

And this all means...?

This approach avoids many errors and omissions common in document assembly programming.  It almost completely avoids re-writing code because of something "new" that pops up (whether in a later template or a new client requirement). It also results in a much quicker and concise system, as there is no "clutter" - every item created has a documented and annotated use, which can quickly be found in my blueprint. If you wish to change something minor, you can quickly look at the blueprint and see what is dependant upon the item you wish to change. No more changing a single variable and then spending hours of time tracking down what went wrong. No more attempting to decipher the system you were supplied with, or figuring out exaclty what F1928 does in your documents.

Personally, I think it is just common sense - review, plan then code, but only once you know everything you need to code for!  For more information, check out the Document Assembly Developer section, where I provide guidelines and approaches to document assembly developers.