NetWorker Blog

Commentary from a long term NetWorker consultant and Backup Theorist

  • This blog has moved!

    This blog has now moved to nsrd.info/blog. Please jump across to the new site for the latest articles (and all old archived articles).
  •  


     


     

  • Enterprise Systems Backup and Recovery

    If you find this blog interesting, and either have an interest in or work in data protection/backup and recovery environments, you should check out my book, Enterprise Systems Backup and Recovery: A Corporate Insurance Policy. Designed for system administrators and managers alike, it focuses on features, policies, procedures and the human element to ensuring that your company has a suitable and working backup system rather than just a bunch of copies made by unrelated software, hardware and processes.
  • This blog has moved!

    This blog has now moved to nsrd.info/blog. Please jump across to the new site for the latest articles (and all old archived articles).
  •  


     


     

  • Twitter

    Error: Twitter did not respond. Please wait a few minutes and refresh this page.

(Semi) Aside – Interesting article on practical heuristics

Posted by Preston on 2009-08-30

Over at Daring Fireball, there’s a link at the moment to Wil Shipley’s article on implementing heuristics within various applications he works on (Mac OS X), particularly focusing in this article on the human factors of heuristics.

As a programmer and an author, I find the article interesting, because the lessons don’t just apply to the software Wil directly works on. Indeed, they don’t just apply to programming at all. Here’s an example – when I was writing my book, I was constantly wanting to come up with a method to reverse the core components. That is, the book title is “Enterprise Systems Backup and Recovery: A Corporate Insurance Policy”, but when you think about it, the more important activity, the activity that people will (or should) think of first, is recovery. That is, from a logical perspective, it would have been more appropriate to layout the book so that all the recovery concepts were covered first, being more important, before the backup concepts.

From a “what the average reader will expect” perspective though, that doesn’t make sense, due to the chicken-and-egg nature of backup and recovery – you can’t recover without a backup, so you still need to introduce backup before recovery, even though backup is just the means towards the end.

Similarly, programming I find is frequently a battle between:

  • What is the easy thing to do
  • What is the right thing to do

Like all large pieces of software with years upon years of development processes (and for that matter, like all other enterprise backup software), NetWorker features a host of situations where heuristics have not been correctly applied; like the situation of the tail wagging the dog, we have several instances I can name off the top of my head where functionality has been implemented (or not, as the case may be) not because it’s the right thing to do, but because it’s the easy thing to do. Some of these are:

  1. No pool selection in the user backup GUI (winworkr, nwadmin).
  2. No inline cloning.
  3. Implementation of the jobs database in RAP format (RAP format is hopelessly inadequate for this task).
  4. No proxying for nsrmmd processes.
  5. The amount of time it took before comment fields were introduced to resources.
  6. The amount of time it took before pool based recycling was available.
  7. etc.

The challenge, moving forward for any company that wants to not only keep their product up to date but to offer compelling reasons for people to switch to it, is to start doing those hard things. There’s a very practical reason for this: the hard things are invariably the things where someone will compare the product against a competitor and say “but the competitor does do this”.

Within reason, every time you take away a “the competitor does do this” argument, you make the product more compelling. One key way to achieve this, which few companies successfully do, is to take control of the company away from product engineering. Product engineering should not control the direction of the product. No ifs, no buts, no maybes. The key people at the heart of all decisions should of course be product management. Why? For the simple fact that product management are (or should be) tasked at understanding the reasons why something should be done, not the objections to doing it. (Other companies, for what it’s worth, suffer the problem of being run by sales people.)

Advertisements

Sorry, the comment form is closed at this time.

 
%d bloggers like this: