Best Practice in Running Mobile Production Environments
What this article is about:
Scenario: You’re the lead developer (or interviewing to be) in an iOS or Android mobile app development production environment for a six-month contract, and the stake holders (Project Manager, Product Owner, Executive Team Members) are relying on you to perform as a guide in ensuring the production environment is running in a best-practice way. What should you consider? How do you drive best practice? Here are some key, high-level areas to drive when acting as a leader in a mobile app development environment:
Requirement Gathering + Business Savvy (ROI and Cost/Benefit Analysis):
Don’t just be a coder or developer – as the lead, you want to understand the business implications linked to any technical decision you choose to implement (the implication to both cost + time).
Example: If I choose to be strategic in migrating our project from Obj-C legacy code to Swift, or at least select portions, what is the ROI and cost/benefit analysis to doing such? Yes, our code base will have the myriad benefits Swift offers, but at what cost to the timeline for delivery and do I have the avail resources (developers) to migrate said code successfully and efficiently without threat to the current operation?
When gathering requirements and making technical decisions, be the trusted advisor and guide to the key stake holders.
Agile:
Most environments are operating in an established “Agile” methodology versus “Waterfall.” Agile working styles will allow more work to be covered in a distributed/horizontal fashion, per the needs of the business/project. It’s a balanced combination of flexibility to meet stake holder and user expectations quickly + efficiently while ensuring there is still a structure and rigor behind the production process.
One- to two-week sprints, daily scrums, demos, and retrospectives are all part of this process to ensuring the work is quality and sound.
Tools to have in mind should address:
1. Code repository/versioning (GitHub, GitLab, etc.)
2. Continuous integration (CircleCI, Jenkins, Travis, etc.)
3. Task assignment (Jira, etc.)
4. Communication channels (Slack, etc.)
Strategic Task assignment:
There are several ways to assign tasks, as well as tools for keeping track. Assigning tasks becomes easier when denoting priority or complexity level, perhaps assigning what is called “story points” to each task. List all the tasks out, compare them across each other in terms of complexity and estimated duration to complete, and this will help you prioritise each task. Larger, more complex tasks are assigned more points, and vice versa for smaller tasks!
Use Jira, Trello, or another method of assigning tasks, and GitHub, GitLab, or the like to keep track of said tasks!
Testing:
A robust testing solution in any given production environment is crucial. This involves a variety of items to consider (method of testing, the types of tests being performed, the testing tools, the frequency of testing, and the protocols around testing code before it’s merged into the main branch). We want to ensure our end clients and users are surprised and delighted with the experience, interface, and functionality, thus testing will ensure the app is sound and doesn’t break!
Test Driven Development (TDD):
Writing the test cases *first* before writing the code – essentially, this is a short development cycle that takes specific requirements (stories) and turns them into test cases – this is done frequently to ensure the code is sound all along the larger Software Development Lifecycle (gathering requirements, designing/developing, testing, debugging, maintaining).
Types of Tests – just to name a few!
1. Unit Testing
2. Stress Testing
3. Instrumentation Testing
4. Automated Testing
Testing Tools – just to name a few!
1. XC Test
2. Appium
3. Junit
4. Espresso
5. Mockito
6. Robolectric
7. Cucumber
Code Coverage / Pull Requests / Paired Programming:
Ideally, and when bandwidth allows in a production environment, we seek to have minimally 80% of the code tested (and more if it can be accomplished!).
In GitHub, we can initiate “pull requests” for code reviews – wherein when and individual developer has completed his piece of code on his individual branch, before it’s merged into the main branch and becomes part of the live production, a pull request is made for another developer (sometimes the “lead”!) to review the code before it’s merged in – another check and balance!
Paired programming: Think about flying an airplane – there is usually a pilot and a co-pilot. One is flying or driving the plan and the other may be navigating the plane – similar concept here! Two developers pair up, and one is “driving” (writing the code) while the other is “navigating” (making suggestions one what to actually write – putting two heads together in this method may result in better code, and each dev may learn from each other, as well!
Architecture:
Whether you’re building an app from scratch (thus you need to define which architecture will be used in the first place) or you’re tasked with updating/modernising the existing architecture (taking it from MVC to MVVM, for instance), it’s critical to understand the purpose of the app, the timeline/bandwidth for delivery, the available resources, and how the various components will be working in the app to make the best decision on architecture.
For example, if I am delivering an app that keeps track of a firm’s projects, and these projects are assigned to specific vendors, some of these vendors may have one or may of the same project assigned to them. In order to ensure the app can allow the multiple projects to be assigned to a single vendor, a 1:many relationship would be required! Knowing this, I would apply Model View View Model architecture (MVVM), as opposed to, say, MVP (Model View Presenter), as MVVM allows a 1:many relationship, whereas MVP offers 1:1 – knowing the requirements is paramount is choosing the right architecture!
Best-Practice Code and Documentation:
When we’re writing our code, we want to ensure a few things are present in terms of being written in a “best practice” way: it’s reusable, it’s testable, there is non-redundancy, it’s loosely coupled, you’ve followed Object Oriented Design principles or S.O.L.I.D. principles. Additionally, documentation around the code (what its intended purpose is, why specific decisions were made, process mapping, entity relationships, etc.) – keep these items in mind when leading devs in the best way to write code.
Have a Plan:
Finally, have a plan! Defining a long-term road map based on the SDLC, available resources, expectations of delivery/release schedules from the stake holders, agile methodology, and competencies of the devs on your project (some may be sounder in UI//UX whereas others may be savvier in back-end work) is a critical consideration. Along the way of this -long term road map, you’re going to set mini milestones (which, again, could be in the format of weekly, bi-weekly sprints) to ensure you’re on target for the ultimate release date. High-level example could look like:
a. 30 days – production environment clean up + optimisation + modernisation.
i. assessing current state, level setting expectations, re-defining processes and technologies, and addressing any existing bugs and perfecting/updating the existing code before moving onto new features.
b. 60 days – could like new implementations + features once the foundation is modernised, optimized, and solidified.
c. 90 days – could look like maintenance, continual updates, and future publish iterations to the app store.
In Summary:
All the above-listed items are just some of the high-level concepts to consider in performing as an “A-Player” lead in any end client’s live production environment, particularly as the lead! Each of these concepts is critical enough to have entire articles devoted solely to them. As you work toward combining technical ability in coding with intelligent business knowledge around effective and best-in-class delivery keeping in mind timeline, available resources, developer capability, stake holder requirements, and end user expectations, you will surely be the “go-to” person for what success looks like!