Sunday, 24 February 2013

User Physics and the Quest for Perfect Software

This post was inspired by the words of Bob Schukai (Twitter @iammobilebob) when I attended the AppsWorld event in Earls Court, 2012 and he spoke of measuring your Users actions to determine the hot and cold spots of your software (among other things - I had hoped to share in greater detail my thoughts on his session but alas the audio recordings never seemed to materialise from the event organizers).
It's been a little while since then (though it may be longer still before I publish this.. who knows how long it will take to write) but I still keep finding myself considering what was said both when using and writing software.

What is good software?

I can't for the life of me remember where I read it now, but I recall someone defining "Good software" not based on the bug count (or lack thereof), but how valuable the functionality is of the software when it is used for it's intended purpose; a bug ridden basic calculator app, among the no doubt thousands available on the web and to down load, could legitimately be classed as a bad application but if the app gave you exactly what you needed to see to get things done but crashed 3 in 4 executions... high bug count but amazing life-changing functionality.  Good Software?
Consider the flip-side too.  An application that even the most malevolent User cannot break, after the nuclear apocalypse it's just the cockroaches and your software, but the software does nothing of any real use.  Good Software?

To take a bit of balanced middle ground.. consider Microsoft Windows. 
There will be, of course, the stead-fast opposers "Bah.. bloody windows, full of bugs and security holes bahhh!..  Bloody Micro$oft..." and the un-swaying fanbois and fangrrls that will declare it to be the Savior incarnate (despite being faced with a blue screen), but let us ignore for the moment those extremist groups.
I use windows, as does Debbie, as do most of the people I know.  I can count only 2 that have become fed up with it and made the move to a different OS (and some of that may have been influenced by the multimedia processing that Mac has always been good at).  The rest stay with it, grant Windows its oddities and carry on.  Why? Because the issues are out-weighed by the convenience and functionality Windows gives us.

Ignoring the obvious issue from NetMarketShare, that appears to have the decimal in the wrong place in the legend (does this make it bad?), the numbers paint a compelling picture for Windows to be Good Software despite all the issues and complaints.

Software - it's all about the User

From a business point of view, successful software is defined based on market penetration, company value as a result of the software as well as internal metrics such as bug counts and met deadlines, but ultimately of course there is only 1 subset of people that has the final say as to whether is is Good Software - your Users.  They are the ones that use it, depend upon it and decide if the functionality weighed against its issues is worth the effort.

Through requirement elicitation, design and User groups we the Developers and Architects can attempt to make software that meets your needs, even when needs change.  We can adhere to your corporate colours, use the tech of your choosing, map your business process to discover things even you didn't realise happens on a daily basis.
What we can't do, however, is predict what those damned End-Users are gonna do 5 minutes after we go gold, what they're thinking or how they're thinking it!

There are 3 possibilities I can think of, off the top of my head to breach this information gap.

A brain read-write device

  • Prevents the User from using the software in ways that were not intended.
  • Ensures that a defined working Methodology will be adhered to, 100%.
  • Any issues encountered during the operational day can be uploaded to the Support system instantaneously, including all actions performed.
  • Requires the abduction of entire user-base prior to release.
  • Requires costly medical facilities.
  • Makes writing the EULA slightly longer and more complicated, but no-one really reads those anyway...

User --> Developer mind-link


  • 1:1 data gathering.
  • Developer learns to think like a User.


  • HR / HSE implications.
  • Can get messy if one of the pair sneezes.
  • Developer learns to think like a User.

Record, track and react to "User Physics"


  • Gives the software house the ability to go as granular as they want to 
    • determine what Users do
    • When they do it
    • how often
    • in what order
  • Highlights areas of high traffic in the application that may merit more focussed attention
  • Acts as an audit trail for the Support team should a problem arise.
  • Can help add importance to a feature request if it can be placed in a high-traffic component


  • Needs to be taken seriously - as with any form of measurement, data is data but interpretation can be subjective; gathering information to a certain level may allow interpretation of hypothesis "x", a higher or lower granularity may produce "y" or "z".  Data interpretation only to the point of convenience is counter-productive.
  • Deep granularity could have a negative effect on application performance (though it would most likely be negligible from a User perspective) and could increase network traffic.
  • Sounds dangerously close to a crappy buzz-word.
  • Less fun than the other 2 options.

Unless Developers can accurately attune themselves with the user-base, we're never going to know how the applications we write effect the people using them (as opposed to the Business) and how the Users employ the software we write on a daily basis.

For now I'm going to opt for User Physics  as my medium of discovery and in my next post on the subject I'll go into some of the things I would do if implementing this concept and why.