Tag Archives: software

Looking back on 5 years of blogging part 4 – Simplicity

Continuing to look back at old posts I noticed one of the themes that has come up a few times is my wish that Legal IT suppliers would keep their software simple.

In fact it’s not just an issue with Legal IT, the product that has highlighted this to me more this year than any other is actually Google+. Google continues to push this product and in doing so bloats all their other products. It’s now in search results, in YouTube comments. Yuk, I long for when Google was just search and a great RSS reader**!

So here are three posts I’ve picked from 2009 and 2010 that distil some of my thoughts on simple design:

First up from September 2009 was a rant at Microsoft for creating IE8 bloatware, thanks goodness they saw sense with IE9 onwards which stripped Internet Explorer right back to basics. Shame Firefox didn’t learn from this as that once great browser is now more bloated than IE ever was! – No, no, no! Who asked for that?

Then in December 2009 was a look at another place where simplicity is useful, policies! I still love the social media policy from ABC in Australia. – “Simplicity is the ultimate sophistication” – social media policies

Last up from May 2010 which re-iterates the first two posts a bit, this time the ire was aimed at Spotify (who’s basic product has gotten worse with all the addins!) – Simplicity rules

** have you voted yet on my poll in the top right? I'm looking to identify what people now use as a replacement for Google Reader.
Share

Following the Pareto principle (aka the 80/20 rule)

An experience over these last few weeks reminded me of the 80/20 rule or the Pareto principle. In software development this is the observation that the first 80% of requirements are easy, the remaining 20% are difficult. And most importantly it’s usually the important requirements, the ones that realise the most benefits that are in your 80% (as you usually focus on the key requirements first).

As a number of software companies understand, once you’ve got your 80% then deploy the software. Yes, we all would like things 100% perfect. But there comes a time in building software that the extra effort to realise that last 20% is just not cost effective. In fact you may be totally wasting your time on working on requirements that are simply not that important or worse completely irrelevant.

8020.jpg

There is of course a risk that you may have an important requirement in the final 20% of requirements. But you could put a lot of effort into those last 20%, significantly delaying the completion of a project, and find none of them were that important.

If you deploy at 80% you get most of the important requirements out there available to the end user faster and you are more likely to identify the remaining important requirements quickly afterwards. You deliver to your customer and can see in the field which remaining requirements are important, de-scoping the rest (and thus reducing the length of your project).

Another great example of the 80/20 rule that I think is relevant to law firm IT departments (or any IT department) is one that I found in Tim Ferriss’ book “The 4-Hour workweek”. That is to fire the 20% of customers who take up the majority of one’s time and cause most trouble.

Now I don’t recommend firing or ignoring the 20% of your customers in the law firm that are the most troublesome! But rather you do not allow your time to be totally taken up by looking after this 20%, rather focus your efforts on the 80% who are as important but perhaps not as vocal in their complaints!

Share

Give them a bigHand!

Sorry, I know that’s a terrible pun!

A warning, this is a bit of a techie post. So for the non-IT readers of the blog, a summary of the post:  “if more vendors/suppliers did what bigHand do in their software design your IT department could upgrade software or change the settings for you much faster!”

On with the post…

As firms grow in size there are a number of IT challenges that can become more and more difficult due to the additional numbers. One of these challenges is those “small” upgrades to get to the latest version that seem to lengthen exponentially with the number of extra desktop PC’s supported. This also goes for changing the configuration or settings of those software applications. Especially when you want to alter a setting that is located locally on the PC (for example, iManage FileSite holds a lot of it’s client settings/configuration in the local PC registry, whereas with Workshare it’s in an XML file on the PC).

bigHand though seem to have a different approach.

At the moment we’re looking at an upgrade of our bigHand digital dictation installation to v3.2.3 and because of this I spent Tuesday on a technical training course for the new version. During the course we went through the client configuration.

And in bigHand for the most part these can be set using roles in the central database. This means they’re very simple to change instantly and also means you can simply manage different configurations for different people. All this can be done without the need to deploy patches, upgrades or do any amendments on the desktop PC.

Other settings for things like drivers to use for microphones can be managed using group policy using the bigHand provided administrative template file (.adm files). Again no mucking about on the desktop PC.

Simple and brilliant!

So if you need to disable a menu option for all the users? Simple! Just amend the role and apply once centrally! This makes upgrades easier as well as your client deployment can be a simple default install without the need to heavily customise for all those specific settings (especially if you have one configuration for fee earners, one for secretaries, one for support staff etc etc).

Share