Now that we understand the implications and challenges of embarking on an Android project, let’s discuss how to find the right firm or developer for the job!
You are ultimately responsible for the application – even if you go the outsourcing route. Things happen, disagreements happen, and turn over happens. The likelihood is high that you will need to maintain the application at some point in its lifecycle. The better the code, the easier the maintenance will be.
There is a wide range of abilities, experience, and knowledge out there. These questions are designed to help you make the best choice about how to invest your Android budget. You need to ensure that anybody you onboard to build the application will advance your organization’s goals and not cause unnecessary rework.
Interview Questions
- What applications have you published in the market? Do you have references we can contact? Describe application features and your role in each application.
- How do fragments fit into your development process?
- What strategies do you use to ensure the user interface will scale to the multitude of Android devices?
- Using fragments
- Using dimensions, styles, and qualifiers
- Using 9-patches
- Using images in different densities
- Wrapping elements and using relative layouts
- Not using fixed pixels
- How do you minimize battery life drain and bandwidth usage?
- Do you unit test your applications? Do you write integration or other automated tests?
- How often will we discuss and decide priorities?
- How will I access the code base?
- Will I get regular builds of the application?
Do they speak positively of their clients and applications? What do their references have to say? How high are the app ratings? Take note of positive and negative comments. If possible, download and try the application(s). This will give you some insight into the quality of the implementation and design.
Do they use similar platform features to what you plan to use? For example, have they only written map applications when you want to create a music streaming application? Keep in mind there is a plethora of platform features, so unfamiliarity with a particular feature isn’t a deal breaker. Great engineers can pick up any new feature very quickly. If something is business critical and you are uncomfortable with them learning this for your application, you may want to look for someone with experience with these features.
Any firm or developer you hire should be knowledgeable of fragments and should be using them. Otherwise, they are writing obsolete code. This technology is nearing two years old and is the way to write Android apps going forward. Frankly, if they haven’t taken the time to learn them by now, how can you trust that they will help you innovate in your application?
If they don’t use them, you will need to completely renovate the application when you expand to the Android tablet market. On the other hand, if they write it with fragments from the start it will be much easier to transition to tablets.
There is a large base of Android developers who remain resistant to learning this new and more flexible way to build applications. I’ve gone on a conference crusade this year to help businesses and developers see the benefits of switching to fragments before it’s too late.
There are many strategies and best practices for making interfaces that scale. Some of the things you’ll want to hear from the developer or firm are:
If they don’t have ideas around this, beware. This is one of user’s main complaints! There is typically a cap on data plans, so users want to limit bandwidth so they don’t get hit with overages. Battery is also a major concern for users. A major factor in battery life is the amount of data downloaded and processed on the device.
Some techniques are using services to complete background work, using alarms to kick of background tasks, detecting when on WiFi and downloading large amounts of data, designing APIs that give incremental data, or detecting when plugged into the wall to do a large amount of processing.
Test coverage is an important judge of quality for the end product. Although it seems like it’s just more code to write, the investment up front will reduce bugs and rework. It may or may not speed time to market, but it will definitely increase the quality of your application.
Developers that don’t use unit testing spend a lot of time building to devices or emulators. This uses significant amounts of time that could be use for writing tests to verify behavior. Plus they won’t be able to find all the bugs by poking around in the application.
Although many Android developers eschew using testing frameworks like Robolectric, setting up new projects with Robolectric, IntelliJ, and maven (or maven + Eclipse) avoids the headaches that come from integrating later on in the project. There are many things you could test, but there are limits and tradeoffs. Check out my article about best practices for testing with Robolectric to help you structure your testing strategy.
Although unit testing in great, there are other types of testing. The more types of tests that are written, the bigger safety net you have when the architecture needs to change. It will help ensure that large changes don’t break existing functionality and find subtle bugs before they get into the wild.
Priorities change – often quickly and without warning. You will encounter challenges even with the best thought out designs. Business requirements will change and it’s essential to keep in close contact with your developers to make sure critical features are implemented according to the latest specifications.
It’s always a good idea to have access to the code. A good practice is to create an organization on github and invite the developer(s) to join your team. They create a repository for your application and save any changes in the cloud. This gives you access to the most updated code as well as the commit history. You can browse code commits to see what they are working on and get an idea of where the project stands.
Although we always embark on new contracts with good will on both sides, disputes with an external firm or developer can happen. Make sure that you have access to and retain the rights of your application’s code. You can’t develop or maintain what you don’t have!
It’s also possible to get frequent builds of the app – either manually or as part of an automatic process. Giving stakeholders access to regular builds is a good idea so that the business can ensure that the developers are creating the features as expected.
What has your experience been with hiring Android developers or firms? How did you determine their skill level? We’d love to hear about it in the comments.