Tim Mackenzie offers mobile developers pointers on when to focus on long-term results for an app and when to opt for the quick fix.
Every app developer will be faced with the dilemma of focusing on long-term results for an app v. getting the quick fix in and getting it done. It doesn't matter if you develop for Android, iOS, BlackBerry, or the mobile web - there are tradeoffs that must be evaluated.
Many managers and customers believe that everything must be done on time, under budget, and have impeccable quality. Oh, and it wouldn't hurt to throw in a bunch of new features. This makes it tough for the practitioner, who must live in the real world.
Here are a few suggestions on when to choose the quick fix and when it's better to take your time and do things right.
Too many features
Is the feature you are working on part of the core draw for this app? If not, time spent getting the app to "2.0" status could jeopardize the chances of getting version one off the ground. Put those awesome (but unnecessary) features to the side for now.
Many of the most successful apps do a very small number of things, but do those things well. Unless your app is supposed to be the Swiss Army Knife of apps, don't get distracted.
Building an infrastructure
It can be tempting to build an infinitely flexible framework so you'll never need to solve this problem again; unfortunately, unless you have a clear idea of when you'll be down this road again, you may be building something that you'll never need again. More to the point: You're taking time away from the current project. As above, it's important to get the initial phase of a project done before worrying about the next phase.
On the other side, there are times when the quick fix isn't the best choice.
Ignoring the details
In the push to complete an app, it can be tempting to ignore small details and save them for the next release. While it is important to drive towards that first release, ignoring an "unlikely" bug can come back to bite you.
I've seen firsthand how an on-time release of an update to an app with a "small" bug has caused bad feedback, resulting in a nosedive in downloads. It's not a good tradeoff.
Cryptic or nonexistent writings
Looking at another developer's code (or even your own, after sufficient time) can be like an archaeological investigation. When methods and variables are poorly named and there are no comments (or even incorrect comments), it can slow things down even further.
Given that no one ever really gets time to just "clean up the code," there's not much excuse for not using at least basic best practices while coding. As we all know, as soon as software works, it gets shipped! You should use good coding practices as part of your regular routine, so you don't have to suffer through your own traps and pitfalls.
Do your duty to explain
Lastly, while you may not have much control over the external pressures for time, budget and quality, you do have a responsibility to explain the situation to decision makers (if that's not you). It might be helpful to understand the focus behind their decisions, and having the discussion (i.e., offering a choice rather than just pushing back) might clear the way forward.
Note: This TechRepublic post originally published on June 8, 2012.