Staying In Control Of Your Mobile App Development Project With A Repository

By John Houghton on April 9, 2015

In my position, I help out hundreds of people who are either investors or stakeholders of mobile development projects and I’d like to share with you what can go terribly wrong if you do not set up and use a repository. This article isn’t so much for established teams at large software companies, but small teams where a basic processes and structures haven’t yet been set up. Let’s say that you’re not very technical, but you need to understand what’s going on with your mobile app development project and stay in control. A repository will help you keep ownership of the project and verify completed work as it happens. By sticking to these tips, you’ll have much better outcomes with your mobile app development project.

The first principle is to maintain a repository to keep your developer’s work, a.k.a. source code. Maintaining a repository is very important and has been a standard practice in software development for decades. The default for new development projects is to send the completed app through email, but this is useless from an ownership perspective. If the developer were to fall off the face of the earth, you can’t do anything with the app. You can’t publish it to the store, you can’t add onto it, you can’t do anything with it. You need the source code and the best place to keep source code is to check it into a repository.

Repository With App Code Stored Safely Inside

If you’re not keeping a repository, it’s possible that you won’t have a copy of source code so that you can keep the project going after a developer leaves the team. This is especially important if your developer isn’t local. Let’s say they get hit by a bus, or they get a better job and stop responding to you. If you don’t have the source code, you have to start over.

Email Is Not A Substitute

If you’re not technical, it’s likely that your developer will email you APK files (Android) or IPA files (iOS) that you can easily install on your phone (or they can use tools like TestFlight for iOS or TestFairy for Android). This is fine for a quick look at the app, but really, you want to get the source code and build it yourself. This insures that you really have all the technical bits and pieces to make the app work.

An easy way to make sure you can build your project is to hire a resource who is not connected with the other developers to act as a Release Manager. Two common repositories I use are Subversion (a.k.a SVN) or Github. If they are not connected with the current developer, they can independently verify the build software and do so objectively. If you have a team and trust them implicitly, it may not be necessary to keep the functions separate, but independently verifying the build might be a good step to make sure everything is in order, get you smarter about what you’re doing, and you’ll be able to step in to push the project along if your release manager is sick. On an active midsize project, your release manager might work 2 – 4 hours a week.

On large software projects at large companies, it sometimes happens that nobody takes a step back to independently verify that the software works. You see these botched releases in the news from time-to-time. That’s why I’m always hands-on, verifying things myself, and always exploring the technical details of the project.

The Job Of The Release Manager

The job of the release manager is to keep the repository organized for a good release. If your project wants to go in a different direction for a while, they will “fork” the code tree, so that you still have the old project and can revert your changes. If the release manager has mobile skills, they can also set up and build your local development environment, which is necessary to verify the software. For iOS (Apple) the development environment is called xCode, for Android it is called Android Studio. The release manager can also prepare the project for release by making sure all of the code is synchronized (important if you have a large team).

I find that at large companies it can be hard to find one person that has all of these skills: development, QA (testing), repository management, and release management (which includes pushing an app successfully through the store). At small companies it is more likely that people have these broader skills. I find that I can be in complete control of iOS and Android projects by keeping these skills sharp. Not only can you save money on mobile app development projects by learning these skills, but you can stay on-schedule by quickly being able to verify other people’s work so that you can advance to the next step.

Since I own my own development company, I find that maintaining my skills is the best secret weapon for beating the schedule. Sometimes when a developer is working late and they check in code at 3AM, I can get up, verify it, and log bugs so they can fix them first thing. There is no delay in getting to the next step. By being hands-on in this way, I’ve never had a disconnect or missed a hard deadline in my 10 years at MobileCast Media.

Keep Your Skills Sharp

Am I asking you to know it all? Yes. Is it hard? Yes, but it is necessary in this day and age. When I was at Oracle, there were business people and there were technical people. Once in a while you would find someone who knew it all and they were considered gods because they knew the whole stack. They were the most invaluable people at the company. You have to be really good at innovating, learning, and retaining what you’ve learned.

For large companies, the bottom line is that senior leaders who work at technical companies need to maintain technical skills. For small companies, if you look at the average app on the store you’ll see that it is horrible. You need to learn these basic skills to prevent catastrophe. Either that, or hire someone you trust, but it’s a good idea to keep your skills sharp.

Next article: Using a bug database (to be written).

Posted in Android Apps, iOS Apps