Archive for the ‘Deep Thoughts’ Category

Everybody is concerned with limiting the amount of data that needs to be reviewed.  It’s the number one cost in e-discovery after all. Clearly, the best way to conserve costs is to review less and there is a technique that we software engineers use every day that can drastically reduce the amount of documents in review. A concept from CS101 called normalization. Essentially, it’s a mechanism for ensuring the integrity and efficiency of a database and provides a framework for specifying the degree in which redundant data needs to be stored. Our goal is to remove redundant data while providing an elegant means of searching and reviewing hierarchical document sets in context.

So here is the typical example we see in e-discovery review.

Email 1 has two attachments, Attachment 1 and Attachment 2
Email 2 has one attachment, Attachment 1

There are much more complex examples of this as well, but this should illustrate the point just fine. Attachment 1 is a duplicate file, meaning it is literally the exact same file, with exactly the same metadata, and the same md5 hash. The only difference is that in one situation it’s attached to Email 1 and in another it’s attached to Email 2.

Most review applications will keep duplicate copies of the attachment and group with the parent emails, essentially flattening the attachment with the email and creating multiple versions of the same pages.  If you choose (or are forced) to review Attachment 1 as two completely different documents in this manor as most common review tools require, you are going to be significantly increasing the time to review, tag, and code that document. Not only that, but you are going to increase the possibility of a redaction not being applied to all versions of that document.

That said, it’s clearly important to look at emails and their attachments together to get the full context of the material. Using the above example, we’ll add titles to each of the docs.

Email 1 Q1 summary has two attachments, Attachment 1 Q1_financials.doc and Attachment 2 Q1_goals.doc
Email 2 Here are the falsified numbers you asked for Jim, Attachment 1 Q1 financials.doc

Even if Email 1 and Email 2 get assigned to different reviewers and they both have to review Attachment 1, the redactions, tagging, and coding information will be available for the other reviewer making the process more efficient than working on that attachment from scratch. You’ve saved yourself a big chunk of time. And in an ideal situation, the same reviewer will already be familiar with that document and see the additional context of both emails during his review. As he’s reviewing Q1_finanicals.doc he’ll know that it was sent out in a Q1 summary email and also in an email announcing that the numbers were falsified. So it’s not only more efficient, it actually sets a greater context for the document and provides additional valuable meta data.

Unfortunately, most review tools that we’ve seen don’t support this normalized relational database technique but our hope is that as more review tools extend to support native file formats this technique for organizing review databases will be available for all.  Our simple and powerful review platform maintains the relationships between all documents and allows for flattening or “reduping” on export or production.  It’s an approach that really provides the best of both worlds.

Read Full Post »

How do we design new features at Nextpoint?  We identify the essence of a feature and get it in the hands of users.  Typically it goes something like this:

1.  We brainstorm… use our imaginations and throw out a lot of “wouldn’t it be cool ifs” without any real consequence.

2.  Identify the major technical hurdles.  Inevitably there are a few.  And that’s a great place to start from a execution standpoint.  Build the proof of concept and make sure it’s doable.

3.  Strip it down.  We’ve already brainstormed all of the details and complexities.  So we just peel ’em away until we are left with the absolute minimal amount necessary to get the core benefit of the functionality complete.  And recognize that we might be leaving a ton of other potential benefits on the table.

4.  Release.  Get it out there and in use as soon as possible.

5.  Improve it based on real-world user feedback.  Often times the ideas during the brainstorming phase come back… but surprisingly many of them never do.  And if they do, we already have an understanding of the concept and have discussed where it fits and the difficulties with implementation.

So basically, we branch out and explore the feature.  Let the scope fly wildly out of control but only on whiteboards and in our imaginations.  And then strip it down to the essence, get in use, and respond to real user feedback.

Read Full Post »

Let Me Out!

I recently made the switch from 30Boxes to Google Calendar. I was generally happy with 30Boxes but just had to give Google a try when it started grokking the Outlook invites I was receiving. The biggest question I had to answer before I made the leap was: “Just how big of a leap is this?”.

The fact of the matter is: Google Calendar was easy to join – and that’s great – but if it wasn’t easy to leave, I wouldn’t have given it a chance. I really like products that make canceling/leaving easy and I’m not the only one around here that feels that way.


If you want to switch your evidence system, it should be easy. It shouldn’t cost you some excessive amount of money and it shouldn’t cost you some excessive amount of time.

Likewise, if you want to “give a new product a chance” – you need to know that if you don’t like it, you can always dump everything back into the old system without wasting too much time and/or money – and certainly without losing any data. The last thing you need is one project stuck over in some tool that you didn’t like.

Of course, nobody wants you to leave their product and take your money elsewhere, but if they really believe in their product: They know you’ll be back.

Read Full Post »

Just Click it.

One of the really cool things about the web and Nextpoint is the ability to create hyperlinks. Nextpoint allows lawyers to take a subset of evidence and make it easily accessible as a link. It’s groundbreaking functionality in the legal marketplace. Its the way users want to look at data today, in stark contrast to the old “file and folder” or local structured database model.

This old model is so hard to use it doesn’t serve as a way to improve access to information, but has become a really cumbersome way to segregate it. This is why we’ll see customers with a deposition exhibits database that is fully redundant with their production database. And multiple databases for the same case. The databases have no simple and easy way of generating and preserving subsets within them. Which means if someone finds a document in the production database, there is no way to see if it has been marked as an exhibit without going to another database. Crazy.

Hyperlinking changes all of that. Discrete sets of evidence (formerly thought of as saved searches) are now generated with the click of one link. One piece of evidence can have multiple issues, tags, deposition exhibit, trial exhibit and traditional coding data associated while being one click away. Lawyers love it because it’s easy, no need to boot up an application, no need to select a window to view, or a field to search in. Want to see all of the Smith deposition exhibits. Just click a link.

Read Full Post »

Love or hate Mark Cuban, you have to admit that he’s polarizing. His recently revisited series of posts on the internet being “Dead & Boring” are certainly no exception.

While I don’t particularly like the “boring” label and I really hate the “dead” label, he makes a good point: The internet is no longer a radically evolving and unstable moving target. We’ve now come to the point where with some good choices and knowledgeable engineers, it can finally be dependably harnessed as a platform. Gone are the days when anything not locally installed could be automatically labeled “unstable” and “not secure”.

Don’t get me wrong, security and stability remain two of the most important and difficult issues in creating any application, but when the ground stopped moving (seemingly) unpredictably beneath us, it became much more practical to build something that can guarantee data confidentiality and security, while not being in a constant state of flux to cope with changes in the substructure.

From my viewpoint, the internet being “boring” is the best thing that could have happened to us.

Read Full Post »

« Newer Posts