Appletell | Apple, Mac, iPhone, iPod | News, Rumors, Reviews, How-Tos

When it comes to developing for the iPhone, there’s no dramatic change in comparison to any other software development project. Aside from the technical aspects of programming for a mobile device, general guidelines have to be followed in order to achieve the highest chance of success.

This is the first of a short (I guess it’d be three of them) series of articles in which I will share some thoughts, explain some ideas, and lay out some strategies to deploy iPhone applications. I’ll be going through everything we need to start programming (ideas, time, skills, docs, tools, motivation, etc), and some of the best techniques to attack a problem and organize a team of professionals (developers, graphics designers, and more).

Even though I’m not an expert on the subject of iPhone development, I’ve been involved directly in the software engineering discipline for a few years now; I’ve had my share of consulting and project planning, and, of course, I’ve written a lot of source code lines by now. 

As an Apple fan, I’ve now been tempted by the idea of writing iPhone applications, I guess I’m not alone here, so I wanted to contribute with my grain of sand (that’s a translation from a Spanish idiom, I’m not even sure it means something for everyone) on this topic everyone is talking about these days. I hope I can count on your feedback here if you have something to add or if you know for a fact that something is missing or incorrect. Your experience and opinions will be highly appreciated. I’m sure we can make this a very interesting column, all together.

Well, let’s get down to business now. After that (questionably interesting) introduction, I’d like to tell you about the genesis of any project, the source of inspiration and emotions every entrepreneur has felt at least once in his/her life: the idea.

Every project, no matter if it has failed or succeeded, has begun with an idea. Some ideas have come from commercial or corporate studies, some other from mistakes, and some of them (my personal favorites) have come to light from a necessity. Maybe the necessity of one person, which ends up also being needed by thousand or million more, making that idea the “why didn’t I think of that?” of the moment.

The idea behind the adventure is one of the key factors of success. The project can’t exist without it, but just having it—even when it’s a great one—doesn’t mean you have anything granted yet.  So many good ideas have been lost in time, on the hands of the wrong people, or in the wrong moment in history, that it’d be impossible to track them all.  We should just have this fact in mind and try not to feed all these statistics of shame. Let’s admit it, it’d be painful to see my neighbor (or some kid from across the pacific) successfully implementing my idea five years after I told him (I could’ve mentioned it to the kid; not likely, but possible), just because when I tried that it wasn’t the right time, or I missed an important feature, even when it was in front of my eyes.

Having a good idea is half the way in the starting days of any project; it would guide you and give you a path to follow. If somehow you find yourself lost with the many aspects of a big project, looking back to the bases, thinking and focusing on the main idea of everything, could represent salvation for your project, and calm for your being.

In the next article we’ll be reviewing what we should do after we got that good idea. There are many options, and I’ll be mentioning a couple of them for those who like to be involved in the programming and/or designing activities (kind of Steve Wozniak), and some other strategy for those of you who have an idea and want to lead the group of professionals to the top of their abilities without getting your hands into the mud directly (kind of Steve Jobs).