Brendan Scott, October 2008
Records Records Records
In the mid 90s I acted for a large government institution in a dispute over the implementation of a failed search engine development being carried out by one of the worlds’ largest developers/systems integrators. As is usual in litigation both sides conducted “discovery” – where you produce to the other side any documents of yours which are relevant to the dispute. Part of the discovery related to the backups of the actual code of the software being developed. In theory each side should have had a monthly back up for 12 months – that’s what they told us. When it came to recovering from the backups we discovered most could not be restored. Out of 24 copies which should have been available, only (I think) 2 could be recovered. Neither of two large organisations (each of which might fairly be regarded as a paragon of record keeping) were able to keep adequate records.
Small and medium enterprises typically have poor record keeping processes. Without records, it can be very difficult to prove any point you’re trying to establish – especially if the other side has kept their own (self serving) records. A good record keeping system will permit you to understand what was happening at a particular time and this can have a lot of important consequences.
Structure Your Records
A record keeping system not only records information, it also structures and stores it in an ordered fashion. This can sometimes mean having to replicate the record in a number of different places if it happens to be relevant to a couple of different things. If you don’t keep your records in a structured way you might, in theory, be able to reconstruct what was happening from the jumbled mass of disparate notes you have kept, but, in all likelihood, you won’t be able to do so as a matter of practice. It is unwise to rely on an after the fact search to find relevant documents. You might choose to structure things implicitly through the file system. Alternatively you can use meta-data in a document management system. However, my experience (now somewhat dated) with document management systems has been that structure is poorly represented (my impression was that they made it easy for me to find other people’s documents, but rarely my own).
Maintain Separation of Projects
A failure to properly structure your files (whether physical or electronic) can have legal implications. For example, if you fail to maintain a clear demarcation between the open and closed source work that you do, the code from one area may contaminate the other, potentially leading to untold heartache. Indeed, this applies pairwise to any two projects you are working on. Particularly important is that you maintain a strict demarcation between any of your personal coding infrastructure (eg common libraries that you may have developed and reuse for multiple clients) and the specific projects you are working on.
For example, if you were to lump your private libraries into a directory shared with a client project that might seem to a judge (who are not renowned for their understanding of coding practices) as if they formed a single work – which may be bad if you’ve assigned IP as part of your engagement.
In some cases records can serve as a substitute for an express contract. Equally, where a contract is ambiguous or apparently overreaching, consistent record keeping can, over time, establish some certainty within that ambiguity or can put bounds on the scope of an overbroad contract. Such records might include, for example, notes of conversations where decisions have been made about what is in or out of scope, or emails which have been sent to this effect. To the extent there is ambiguity don’t be shy in recording your understanding of the events. While courts may not necessarily take your view of the world (as instantiated in your records) as gospel, it’s better than having nothing. Send the notes to the other side prefaced by something along the lines of “This is what I understood we are doing going forward: ….” This gives them an opportunity to correct you if you’re wrong. If they don’t it will look odd for them to argue it was wrong at a later date.
To the extent practicable notes the date the note is taken should be included as part of the note. This makes it easier to date the note – which can be crucial. Often cases ride on when a person knew or said something. If you have an undated note of what was said, it may not end up helping your case if you are unable to place it in relation to some critical date. For example a note that the other party said “don’t worry, the contract has nothing in it that you should be concerned about” will have a completely different consequence if it can be proven to be said the day before you sign (perhaps it induced you to sign) as opposed to the day after (when it can have had no effect on your decision to sign). In addition, courts will generally pay more attention to a record which is contemporaneous with the details it records rather than one which attempts to reconstruct the situation at a later date.
Never use automatic date fields in documents if they will auto-update at some later time. Date fields may seem like a good idea at the time, but once they update, their value is lost. If you must use date fields, have some process by which they are converted to plain text on save (eg when the note is finished, or the relevant document has been sent).