Nov 13 2007   3:07AM GMT

Expectations in Software Development

Posted by: Joe Coley
Agile, Business process automation, Custom software development, Database application, Database application front-end programming, Software Quality, Software maintenance, Software testing, Software application development

I’ve heard it said before that an expectation unfullfilled leads to upset, and I must honestly say that I buy into that 100%.  How many times have we begun using a new piece of software with an expectation (or 2 or 3) that was left unfulfilled once we started using the software?  I believe that I can say for certain that it has happened to each of us on at least one occasion - leaving us upset because the expectation (probably unrecognized and undefined beforehand) was not met. 

With this in mind, I would like to explore some thoughts regarding just what some unspoken expectations for software are.

User Friendly - Easy-To-Use

I’ve blogged before about user interfaces, and the value that a “clean” user interface brings to the table.  While many specification documents may state that a program be “user friendly” or “easy-to-use”, putting some measureable parameters around those qualities is certainly a daunting task.  Users expect not to get themselves into trouble using an application — so I believe that this is an expectation  users have.

Bug-Free

Valid expectation or not I believe that users expect bug-free software.  As developers I believe we owe it to our users to test as completely as possible before putting our users to the electronic wolves of a buggy piece of software.  Testing with large amounts of data is best whenever possible — “real” data, meaningful data that truly tests the intricacies of a program are obviously best.

Fast - Smooth Flowing

Users don’t want to wait — and “clunky” just doesn’t work for them.  But again, how do you measure it?  There can be a significant difference between testing in a test environment and running in the live environment.  Chances are the live environment will be subject to much more network traffic and resource consumptions at all points along the path.

Not Restrictive

Users do NOT want to be restricted in what they can do — but they also don’t want garbage in their application data.  As developers we seem to balance delicately between ease-of-use (call it user freedom) and allowing users to get ahead of themselves and into areas where it gets messy.  Data integrity checks along the way are a must!  Graphical interfaces are great for allowing freedom to the user - but there were many good points to the old character based systems that forced a flow - properly designed it was fast and trouble free.

Work as Advertised - Work as Expected

Users don’t want double talk — if a program is supposed to interface to a scanner then there is also some expectation regarding “how” it will interface.  If it is a nightmare to use it, it might as well not have the “feature”.  In the eyes of the user it doesn’t work as advertised.

Pick any expectation and you would probably be able to find many varieties of the expectation — some which you may hae guessed, most of which you probably won’t. 

In closing, once again it seems that we’re back to the idea of communication at all levels being key to providing a quality user experience.  Quality software doesn’t just happen — it takes a LOT of work, a LOT of communication, and sometimes a LOT of luck finding the right combination.