How to build Excellent Software

Requirements

It does not matter what language, database, framework or methodology you employ making excellent software requires a strong focus on 2 major aspects and then an iterative end user focus on their use. The most important aspects to focus on are responsiveness and accuracy. 

Responsiveness

Any request must be actioned in a timely fashion, and if possible always faster than the end user can keep up with. Yes there are plenty of processes which are so computationally intensive which require second, minutes or even hours to perform, however, it is vital that the application is responsive. If someone presses the "compress video" button then you should be immediately aware that you have successfully pressed the button, hopefully there should be an ETA on the process and/or % completion time.

It can also be a good idea for an application to remain responsive while other actions are being performed. So you are compressing a massive file, is the user likely to want to select another file to compress? If the application runs in a different thread perhaps you can queue up the compression of the next file while the other is processing. By allowing the user to perform extra actions while the "slow" processes are running in the background they do not feel like they are waiting for the application they are performing the additional tasks they would need to do anyway, rather than wait for the slow process to finish and then perform the actions later.

It is vital that anything that is less computationally intensive is processed so quickly that the device is waiting for user input and not the other way around. It is important to work on the most common pathways first to make sure these are all as responsive as possible.

You can manage user perceptions of speed through transition effects. Normally a button will need to update its state very quickly so that the user is not left wondering if they clicked successfully or not. These UI elements will normally need to update in the sub 100ms region. In terms of altering state on the screen in response to user interaction this can be slower, but you should aim to be less than 300ms if possible. If the task will genuinely take longer than 300ms it is important to consider what can be done to make the customer not feel like they are waiting around for your software. Can you pre-process the data before the user has completed the task, is it possible to guess their next action?

A simple case is the "Find" function. When someone performs a find on a page it is highly likely that their next action will be to "Find Next" pre-processing in the background to find the next item can dramatically improve the responsiveness. Similarly paging through a document or table, pre-loading the next page can really help, perhaps even pre-loading the next and last page can make your application feel like lightning if it helps bring your performance from over 1 second down into the milliseconds.

Another aspect of responsiveness is being able to cancel long running processes. Sometimes you can accidentally trigger a long running process. Any process which can take over 1 second to complete should have a cancel option. The cancel option should act immediately, even if the cancel action is not instant try to make any roll back actions occur in the background to prevent the user being stalled on a cancel screen wondering if they would have been better off just letting the process complete.

A responsive application not only feels like it is built well, but invites exploration of the application, the user knows that they will not be waiting for ages if they click the wrong option.

Accuracy

The application must work with accuracy. For example a navigation application should lead you to the correct location and not a field in the middle of no where. Any time a user experiences something that is not accurate they will lose confidence in the application. This confidence means that people can not use features of the application even if the feature was fixed years ago, and even if they are told they are fixed they will be wary of them and will more likely conclude that any issue they experience was the fault of the application rather than their actions. Essentially they will be very willing to switch away from an application that they consider inaccurate to any available alternative.

The only real way to achieve accuracy is through extensive testing and bug removal. Unit testing, automated testing are beneficial, but these will not pick up that the end user finds some of the language you have used as ambiguous or that some of your use case assumptions are wrong. My favourite option is the introduction of "expert users" into the development process to evaluate, test and help guide the development process.

What about features?

Features are important if software does not perform vital features then it is useless, but feature richness is always a distant 3rd in respect to responsiveness and accuracy. How many times have you picked the slower or more buggy software because it had features that the other software did not, I suspect the answer is a lot less frequently than the fast, relatively bug free software.

Once the important features are available, responsive and accurate then it is time to look at user actions, are their features the customer would love, are their common tasks you could better automate for them. One area to really be careful of is adding features which add complexity to existing functionality. For example say you add the ability to save your application to an online service. No one can complain about this new enhanced ability, however, what if when you add this save functionality to the application you require every save action to choose between a local save and a cloud save every single time. Suddenly this new feature will cause a user revolve because it is one more click required to perform a common action than it used to have.

Actually user perception to change can sometimes surprise you. I have seen users that are so adverse to change that even reducing the number of steps to perform a common task can be seen as a bad thing. To make your excellent software perceived correctly so it is also important to counteract any aversion through early education and if possible involvement in the change process.