This is a crucial question that will have lasting ramifications for YOU, the developer. If you are a subscriber to the HotDocs ListServe, you will likely have seen the arguments on this very topic before. I have worked with, and created systems using both approaches. If given the option in my client works, I will almost invariably use shared component files, due to ease of maintenance. With the blueprint I create prior to programming, it reduces maintenance times to almost NIL - it is one or two changes.

The arguments for and against single/shared component files generally come down to this:

• Single component files are easier to set up initially because every template can be coded in complete isolation to all other templates. Each template is an 'island' and you only have to make that island work by itself, not in connection with anything else.
• Shared component files are easier to maintain and work with, because most document libraries have a few core concepts (ie: plaintiffs/defendants are handled almost identically in every UCPR form in the country). Shared component files allow you to code something once and re-use it across multiple templates. Update code once per library instead of once per template.

The rest of this articles deals with the pro's and con's of each approach.

Single Component Files

A system using single component files is one where each template has its own component file. Each template contains its "own" code which is in no way reliant on any other component file in the system - each component file (and associated template) is unrelated and unrestricted, running independently of "the system".

Pro's

• Programming is "easier", as you can use any variable or dialog however you feel necessary in each and every document. How you program in document #1 will not affect the "flow" or coding of document #2
• HotDocs 6.x and 2005 now has many in-built functions that make using single component files easier to manage and keep consistent (but managing to keep 50+ component files consistent can still be trying)
• If a certain template isn't working as intended, or users request "more" programming in it, you can edit and update that template in isolation to any other template in the system
• If a component file goes "corrupt", you only have to re-create one template's code
  
  * In this respect, you should have nightly backups running on your HotDocs templates and component files, so this should not really be an issue

Con's

• There are many things in many systems that are "central" to a matter type - "plaintiffs and defendants", "borrowers, lenders and mortgagors", "client, spouse and beneficiaries", "lessor and lessee" - in a single component file system, you have no ability to centralise these central concepts - every template is individual!
• If you use variables of the same name, but serving a different purpose in two different component files, your users' data may become corrupt and subsequently be lost
• Updating automatic data (such as author names & details, lists of courts, DNR registries, liquidators, mortgage managers and the like) is a nightmare - it has to be implemented in every template that uses the data being updated
• You cannot easily create a single interview that is usable by multiple templates - the interview must be manually copied to every template that needs to use it. If you want to upgrade that interview, you must do so in each individual code file for each template that requires it.
• Adding new functionality to a system or template set becomes problematic, as it must be included manually in every template's component file
• If you need to upgrade your HotDocs version, you are going to have to convert every single template's component file, and then check every variable and every dialog in every template
• Encourages "sloppy" or "hasty" programming due to each component file being independent of each other
• More difficult to track down where "strange" or incorrect data is coming from in an answer file
• Templates, variables and language invariable becomes patch-work and inconsistent

Many of these issues are substantially alleviated when using very strict naming schemas for every variable and dialog. When combined with a spreadsheet or other tracking document, duplicates can be analysed outside the system, and changes become obvious. However, you still have to implement those changes or upgrades in each component file, not just identify them.

Shared Component Files

A system using a shared component file is one where every template "points" to a single "master" component file. In essence, every single template in the system is running off a single code source.

Pro's

• You become a better coder faster, by ensuring that your document assembly system is consistent across the board for every template in the system. You can't take shortcuts!
• It is very easy to design interviews on a template-by-template basis or to have interviews that are re-used by numerous templates.
• There is no need to copy components to make them uniform, as every template is using a centralised code source
• No matter what issue is identified in the system, there is only one place to look for the code to fix - the central component file. On the same note, you don't ever have to worry about which component file you have open at a given time - there's only one!
  
• Even if your firm doesn't have backup systems in place, it is the work of 2 minutes to manually backup and date stamp your central component file
• You cannot use variables of the same name that serve different purposes, as there is only one code source. HotDocs will prohibit the attempt to create identically named variables
• Updating automatic data is cake - change it once and it is immediately accessible by every template in the system. Change authors, mortgage manager detail lists and liquidators ONCE
• Adding new functionality has to be done once. Its amazing how tricky you are able to be when you only have to create a solution once, instead of creating it once, then implementing it in every template (and hope that each subsequent template's component file wont need editing to make the solution work!)
• Sloppy code wont work well, and hasty code probably wont work at all - your skills at programming and planning will be honed within a month or two, ensuring faster and more efficient document assembly works in the future
• If there is strange data coming in to your answer file, you can review your central component file's INTERVIEW computation (or equivalent) and see every single dialog that is asked, every piece of data that is populated, every template that is assembled - and in what order.

Con's

• It is more difficult to get it right initially
• If your master component file goes corrupt, your firm doesn't have backup systems in place and you haven't manually backed up your component file, you are in for a lot of pain. In this case, I sincerely hope that you have a blue print of some kind, otherwise you'll be re-programming from scratch, unless you can salvage some of the component file manually

Like many things in the software industry, it is a case of "easier and faster up front with reducing returns in the long run" -versus- "more difficult/costly to set up right, but continued returns and easy maintenance & upkeep". Like all things related to software systems, the initial time and monetary costs pale in comparison to the ongoing maintenance and support costs.