Unleash Your Inner App Developer Part 39: 7 Steps to Being a Better App Developer

Do you have an idea for an app but lack the programming knowledge to begin building it? In this weekly blog series, I will take you, the beginner app developer, step by step through the process of creating apps for the iPhone, iPod touch, and iPad. Join me each week on this adventure and you will experience how much fun turning your ideas into reality can be! This is part 39 of the series. If you are just getting started, check out the beginning of the series here. 

Are you proud of the code that you write? Are you using a set of best practices that allows you to develop well-designed, stable apps that can adapt to change?

As part of what my company does, I am often asked to evaluate software development teams as well as the apps that they have created. As you might imagine, I see the good, the bad, and the ugly. Unfortunately, most of what I have seen is definitely in the "ugly" category. Often, I need to change a company's software development culture to pull them out of a tailspin and get back them on track.

In this post, I'll share some of these basic principles that I instill in software development teams, because they can be used to elevate your craft as a developer and vastly improve the apps you create.

Step 1: Be an Architect

Earlier this year when I was speaking at the Apps World conference in San Francisco, I sat in on a session from one of the directors of mobile development at Twitter who was speaking on the subject of "Developing for Billions." In this session, he discussed, very frankly, the problems caused by the developers at Twitter not having a solid architecture that allowed them to scale to meet demand. The state of Twitter's software required a major overhaul in order to meet the demands of scale and to accommodate all of the change requests they received.

I find that that poor architecture is one of the problems that can have the most damaging effect on an app. If someone hands you a change request and you want to throw yourself off the roof of the building because the change requires you to completely rework your app, someone hasn't done their job as an architect. 

An app with a solid architecture keeps the main parts of the app (user interface, core logic, and data) separate, so that changing one part of the app doesn't require a rewrite of the other parts. For example, what would happen if you need to change your app from accessing data locally to accessing data in the cloud? If your app is designed well, this should be a relatively easy transition.

It really comes down to a question of "Where do you put your code?" Every member of an app development team has to wear an architect hat, understand these basic principles and apply them on a daily basis.

For more information on creating a solid architecture, check out my earlier post on the subject.

Step 2: Use Other People's Code (OPC)

A while back I was asked to settle a technology dispute among members of a development team (yes, it was as "fun" as it sounds.) There were four different camps within the team, each with their own ideologies. Each camp refused to use solutions developed by another one of the warring factions. As I examined their code base, I noticed that most of their solutions weren't that different from the others. They were just different ways of approaching the same problem. The owner of the company was not pleased to hear that he was paying for problems to be solved four different ways.

This is an extreme example of developers who have the "not written by me" disease that causes them to write all of their code from scratch. This is not a best practice. There are lots of free and inexpensive high-quality code libraries that you can incorporate in your projects rather than writing everything yourself.

Whenever I begin the process of adding new functionality to an app, I always do a quick search to see if someone else has already written code that performs the functionality I need. It may not be exactly what I want, but I can often adapt what someone else has already spent many hours developing to get to my end goal faster. When checking out code, I recommend scrolling down to read other developers' comments before trying to implement it yourself. A great first place to look is Apple's code samples.

The StackOverflow web site is also a great source for code snippets and code library recommendations. Readers vote on answers, so it's easier to quickly see the suggestions that are worth your while.

Step 3: Stop Solving the Same Problems

When you solve a programming problem, whether it's big or small, you should also solve it for all future apps that you create. How do you do this? Rather than just documenting your solution, you should create an application framework that you can use in future projects.

An application framework is basically a set of classes you create that extend Apple's Cocoa Touch framework. Often these extensions take the form of Objective-C categories, which allow you to add methods to existing classes. If you haven't worked with categories before, you can find out more at this link.

For example, if you need to find the number of occurrences of one string in a second string (for example, the number of occurrences of the string "ain" in the phrase "the rain in Spain stays mainly on the plain"), you could create a category that extends the NSString class.

For a more complex example, if you want to add the ability to save entities asynchronously on a background thread, you could create a category that extends Core Data's ManagedObjectContext class.

Over time, you will create a framework of extensions that you can use in many different projects. This is a far better solution than what many developers do instead—copy and paste! This is one of the biggest sins I see repeated over and over again, even in large professional development shops. It takes just a few extra moments to create a category or another type of framework class that you can reuse rather than copying code from one method and pasting it into another method.

Why is duplicate code such a big problem? If that code has a bug in it, then you have repeated that bug in many different places. Also, if that code ever needs to change, then you have many places to change it rather than just one.

Step 4: Use Coding Conventions

Before I started my own software company, I worked for a company that had strict coding conventions. One of those conventions was providing meaningful comments for your code. One of the other developers I worked with insisted that he couldn't add comments to his code as he was writing it, but that he would come back later on and add the comments. Of course, he never went back in and added his comments, and when he left the company several months later, yours truly had to sift through his code to figure out how it worked. Coding conventions make it easier for yourself and others to look at code written several months ago and quickly understand how it works. 

If you haven't done so already, I highly recommend reading the book Code Complete by Steve McConnell. Not only does it talk about the need for coding conventions, but it also covers defensive programming techniques, building quality into your software, and many other software development practices that will vastly improve the way you design and write your apps.

Step 5: Be Able to Say "It's My Fault"

A few years back I was working with a software development shop that needed help making their apps more scalable. Over the desk of one of the senior developers was a sign that read "It's My Fault." When I asked him what it was about, he told me that none of the junior developers would ever take responsibility for their own bugs, and the development team's progress was mired down in finger pointing, rather than moving forward with bug fixes. He decided to set the example by being willing to say it was his fault.

I highly recommend reading the Time magazine article that talks about how the HealthCare.gov web site was restructured to become a successful, scalable web app. A lot of this had to do with the culture that was put in place that allowed developers to feel the freedom to admit their mistakes. I particularly enjoyed the story where Mike Dickerson of Google, who was helping fix the broken web site, demanded a round of applause for an engineer who called out from the back of the room that a brief outage had probably been a result of a mistake that he made.

Step 6 - Respect the Client

I have three basic requirements for all developers that work for me:

1. Keep up to date with the latest technologies
2. Know when to ask for help
3. Respect the client

Yes, as an app developer, you are smart. But just because a client doesn't know know how to write software, that doesn't make them dumb. Honestly, I find the most insecure app developers tend to have the largest egos. Those who are comfortable with their abilities don't need to constantly impress everyone else, and are able to give greater respect to the client's in-depth understanding of their particular business domain.

When you assume the client doesn't know what they're talking about, you end up writing the software you want, rather than the software the client needs.

Step 7 - Never Stop Learning