If you're in the business of producing software, be that for a particular computing platform, the web, mobile or whatever, there are a number of considerations that should be taken on board before it leaves your development environment. Without careful planning and foresight, your beautiful app could,at best, be used once and never touched again – at worst, never actually up and running in the first place.
This isn’t just technical resilience – this is resilience to anything that could be thrown at your application, from system requirements to end user expectations.
Internal or external?One of the most basic considerations – is your application going to be used just by you (or if you’re in an organisation, your colleagues), or is it intended to be consumed by the world at large.
If you’re making an internal application, chances are you won’t need lot’s of bells and whistles to hand-hold the user at every twist and turn. But if it’s going out into the big wide world, then it becomes a very different matter...
What operating system is (or could) it potentially be used on?Look at what your application is trying to do. Does its functionality relate to a specific OS, or could it potentially be useful on any platform? If it performs a niche task such as administering users within Active Directory, chances are you’re going to be targeting Windows users only. But what about a more general app, like managing personal finances? Could you benefit from porting to some other major operating systems?
Are different operating system versions going to affect things?Your hip, hop and indeed happening application might work at treat right now, but what about in the next OS version coming out next year? You haven’t heard? Yep, that’s right, they’re ripping out some core aspects of the system that’s going to cause your application to give users some horrendous venereal disease.
Keep up to date with changes in all operating systems that your application is designed to run on, and make sure it always works.
Does it need a particular framework?As almost a subset of the operating system, certain applications written in certain programming languages will always require certain frameworks. Again, keep up to date with any that your pride and joy might be relying on.
If users are having difficulty using a particular framework, either from it being a brand new version or otherwise, consider alternatives or even paring back unnecessary functionality that requires the problem framework.
Does the user have to question it’s intent?Is your application so straight forward that a toddler could use it, or does it require some brain power just to get it fired up? Never make assumptions about the user – if you have the slightest tingle that something could be misunderstood, then it probably will be. Provide enough prompts to get people to where users want to be.
Is the interface/flow consistent?Does your application look and feel the same all the way through, with repeated controls appearing in the same position throughout? The same colour scheme used? The same navigation method? The same terminology? Or does it look like you employed Salvador Dali as a user interface designer?
Inconsistency will lead to your application being dropped faster than you'd like to imagine.
Is a rollback facility offered?If your application terminates unexpectedly, or the user decides they no longer want to proceed with a particular operation, can your application take them back to a warm safe place? Make sure original settings are saved, backups made and warn the user as much as possible about what is taking place.
This should be high on your list of priorities, especially if you are making changes to existing files or settings.
Are exceptions handled adequately?Hand in hand with a rollback facility is exception handling. If your application displays unreadable system errors by default, you’re doing it wrong. Make sure, in as plain English as possible, that your users know exactly what happened, what’s going to happen next, and what they can do about it.
Is your code clean?Can you read your own code? Is it cohesive? Does it follow any patterns, or adhere to any guidelines?
If you suddenly have to bring someone else onto the project, how long will it be before they can actually get working, after deciphering your hieroglyphs?
Keep your code sensible, adopt best practice methods, refactor and reuse as much as possible.
These are but a few pointers to try and ensure any application that you produce remains up and running, no matter what’s thrown at it. That includes system upgrades, language changes and, of course, user input.
