In an ideal world, development is a carefully thought-out process where each stage can be carefully considered and each further step planned out in advance. Unfortunately, the real world rarely plays out how we’d like, so having a good plan to deal with rapid development needs and changing situations is always a good idea. Planning for worst-case scenarios can generally be thought of as good practise – after all, when time is short, mistakes can be even more critical and costly than they usually are.
In the development community, one of the most important, but least-often appreciated tools at your disposal is the community itself. From the get-go, choosing a development system which has a good network of users and makers can shave countless hours from your development process. This goes doubly true when it comes to error-checking and bug squashing: by choosing a system which has a robust community, you’ll be able to fall back on methods and a knowledge-base which has already encountered any issues you’re likely to face.
Another important consideration when working under strict time limits is to have a very clear idea of what you hope to achieve. Rushing a project which tries to do too much is likely to land you a product that fulfils less aspects of your brief than if you had tried to do one thing simply and well. It’s possible to work development miracles, but it’s not something to count on: having a good idea of what you can realistically do well in the time you have is worth much more than making promises you can’t keep. When time is short it is not the time to experiment; stick with systems you’re familiar with, and you’ll be that much more likely to deliver on time.
Having a good knowledge of what systems work best for what you’re trying to do is essential. There are a few ways to approach this choice, with one question to consider: do you want to be able to expand and enhance your product once it’s up and running, or are you better off finding a solution which does what you need to right now well? Many modular systems exist which allow additions over time, but sometimes a package which delivers a simpler and more attainable result will be a better bet. Added functionality can sometimes mean added complexity, which only increases the dev time you’ll need, and that’s without getting into the likelihood of increased errors and compatibility issues.
As with many situations where time is tight, a bit of planning can go a long way, and save you time down the line. Having a comprehensive plan of action for situations where rapid change will be needed is always a good idea. Whether it’s things like having a content library with assets that work on a variety of formats, or building responsive modules before they’re needed, or even having new elements ready to go live at short notice will all make the rush that bit easier to handle.
Being able to handle rushed moments in developing is easier than ever in many ways – the vast majority of major languages and systems are built to be easy to use, reliable, and robust. The key to being able to deliver on new mobile projects quickly is often in your initial choices – so planning for the need to produce quickly should be one of your first considerations once your development business is up and running.
