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:
- No pool selection in the user backup GUI (winworkr, nwadmin).
- No inline cloning.
- Implementation of the jobs database in RAP format (RAP format is hopelessly inadequate for this task).
- No proxying for nsrmmd processes.
- The amount of time it took before comment fields were introduced to resources.
- The amount of time it took before pool based recycling was available.
- 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.)