Mobile Lead 101 — Lesson 2: Move fast, fail fast, fail-safe
What I learned working as a Mobile Lead for seven years
This article describes some of the tools that helped my teams to deliver several projects on time and with high quality. Achieving this, it is a fragile trade-off between architectural foundations, technical debts, designing for growth and the velocity of new relevant releases.
Move fast: It is a classic!
Have you ever worked in a company that is not interested in adding an incredible amount of new features or upgrades in the next release?
In some companies, you can experience a constant fight between PM/POs and developers. The PM/POs thinks that the developers are lazy or too interested in their technical details and the developers believe that the PM/POs don’t understand anything technical (coding is not like doing a PPT).
The development of new features or a new project is a complex trade-off between timing, quality, people and future scalability.
It is not just a matter of how many features can a team develop in the next release, but also how. What is the level of reusability, code quality, maintainability expected? How can you explain to the business that you can rush today, but then you will pay the price tomorrow when developers take three days to fix a bug, or they resign because the code is too messy?
It is hard to stay in the middle between the technical and the business worlds. Having a robust delivery track record helps, but you can’t argue to your bosses by just saying: “Please trust me”. I created a few equations to explain it:
Variable definitions:
- New features: it represents an estimate of the number of new features that could be delivered by a team in a release;
- Squad capacity: it is a measure based on the past track record of how many epics (defined with a t-shirt sizing methodology) are delivered in a release; it takes into account several parameters from technical seniority to the percentage of new joiners in the team
- rqmtsClarify: this variable express the detail of the business request and the quality of the requirements
- targetQuality: it might be a hidden variable of many projects. Usually, it is not explicit told, but the timeline and the code itself can imply it. It takes into account the expected code quality of the new releases.
- codeBaseQuality: it measures if the project is easily maintainable and scalable. Are the proper design patterns and architecture in place? What is the size of the project and how different features are connected?
The above three equations help explain to management how the ability of a team in delivering new features is impacted by the current codebase quality, the seniority of the team and the new features target quality.
In the short-term, an organization under stress can deliver features faster, but there are relevant implications in the long term to remember. In this scenario, the team will invest less time in creating reusable components, reviewing the code and refactoring with the proper architecture.
The goal of explaining the relationship between reusability and long term scalability, it is critical to buy time from management to put in place the proper foundation. Besides, when the code becomes a nightmare, and the administration is pushing hard for deadlines, many developers will not last in the company causing a vicious circle that usually causes an entire project to derail.
The above three equations are not a perfect science like the Pythagorean theorem. They can be useful to remember about all the factors that are impacting software development. It might be helpful to drive your conversation with the PM/POs to explain the implications of some decisions.
The move fast enablers
In my experience, the primary enabler for a scalable, maintainable long term mobile project are:
- Design for growth
The development team should be engaged since the earliest conversations to be able to understand the scope and the long term roadmap. Before writing hundreds of lines of code, the team should meet face to face agree on basic design and architecture principles. It is a crucial moment to make a decision that will help improve the scalability of the project. Some project needs (number of screens, number of contributors, number of Regions) might have a substantial impact on the architectural decision.
According to the complexity of a project, I recommend some essential tools to help a project growing over time such as the clean architecture (android and iOS), the modularization (android and iOS) and the micro-frontend architecture. All the previous patterns are not mandatory. It is vital to pick the few that your team is willing to adopt, and it is compulsory to be consistent across the entire project.
This accent on design will help not only to scale faster but also to implement the proper separation of concerns that is a pivotal achievement to increase the code maintainability. - Code standards
In every project, developers have a different point of views on coding. I recommend creating and updating weekly confluence pages on guidelines, best practice, checklists (entry/exit criteria, the definition of done, etc.) and new joiners guides.
It is a critical exercise to align different development teams and keep only one source of truth about the project. Your project will benefit by improving the code reusability and maintainability. Also, your organization might be decreasing the time to onboard new developers.
A recommended book about coding guidelines is “the clean code” book by Uncle Bob (Robert C. Martin). - DevOps for mobile
The principle is natural: all the repetitive task of CI/CD should be automated. You will benefit from higher efficiency and less human errors. But it isn’t trivial: iPhone requires MacOS machine to run the pipeline that is not available on AWS or Azure. My preferred tools are Fastlane, Jenkins, SonarQube and Firebase. Your developers will help more time for coding. Also, I recommend the introduction of a mobile release manager to coordinate all the efforts of your team. - Test-driven development
TDD is an innovative software development approach where tests are written by the developers, before writing the bare minimum of code required for the test to be fulfilled. The app code can be refactored, as often as necessary, to pass the test, with the process repeated for each piece of functionality. In this way, instead of writing useless and not in sync documentation of your code, your tests became your software requirements. Indeed, it helps to create better modularized, extensible and flexible applications. There are some guides (android and iOS) that might help you start, but it will require years to become a pro.
Fail fast: the MVP principle
According to Wikipedia: “A minimum viable product (MVP) is a version of a product with just enough features to satisfy early customers and provide feedback for future product development”. You can apply this concept also to features. Nobody can be so sure about what your customers want.
“In order to innovate, you have to experiment”
Mike Schroepfer, CTO @ Facebook
Waiting for months to go live with a super detailed feature instead of delivering iterative upgrades since week one postpone revenues and increase the costs and the risks of royalty screw a project. I think MVP is a well-known principle that doesn’t require further explanations. Remember that you can apply to each level of a project from small features to enterprise solutions. As a lead, please make sure that it is always brought to the attention of project teams, especially during prioritization or grooming sessions. If you would like to know more, you can read this famous book “The Lean Startup” by Eric Ries (a summary).
Fail-safe with feature toggling
Should we wait for all the approvals before starting to develop this feature? Of course not. In some project, with this attitude, you will never deliver anything. Please try always to start working on a feature as soon as possible.
There are many reasons why a feature might not go live:
- The business team (i.e. marketing is not ready; some details are not yet approved by leadership, etc.) is not prepared.
- The feature needs legal or regulatory approval that will arrive late.
- Other technical teams are not ready.
Some project manages this risk by avoiding to merging the code until the last minute, but in the long term is not a good practice. The code, after a few weeks, is out of sync and you will need much more time fixing conflict when everyone is finally ready.
The approach to addressing this problem is to create a feature toggling mechanism. This mechanism will allow the developer to merge their code and to enable or disable a feature from the back-end side. Sometime it might require to add some additional code, like to keep version one and version two of functionality. Still, the benefits in terms of flexibility are way higher compared to the small application size increase you might end up gaining.
How does it work?
- Ask your back-end team to develop a new service that will accept your user or device identifier, and it will return a list of service enable/disabled and the current version. This service should be super optimized for fast response time.
- Your mobile team should change the logic for application start. At every app start (or with a tailored caching mechanism) while loading, it should call the feature toggling endpoint and retrieve the app configuration.
- Based on this response, the proper entry points of the relevant features should be displayed or hide.
This feature can also be used to enable an A/B testing capability by adding additional logic on the back-end and by allowing some functions only for some target users.
Conclusions
Moving fast is essential for a project; it enables to anticipate revenue that might be critical for a company. But the development team should not be a victim of the business decisions. There is a complicated relationship between speed, quality, team motivation that should be brought to the attention of your business team. Listen to the technical point of view on the different delivering timeline plans, and it will help you to improve code quality that implies higher maintainability and scalability for the future.
In this article, I described several enablers for the technical team that might be helpful to deliver faster and safer. The proper design and principles like the TDD, clean architecture, modularization and MVP principles are foundations for any project that is willing to change to user needs and scale.
Please contact me for any feedback about this article. I would love to discuss this topic and collect a different point of view about it.
About the author
Since 2012, Francesco managed six mobile projects as a Mobile Lead or CTO. He covered several industries, from banking to lifestyle. Francesco led teams from one to sixty developers in four continents. In his project, he used technologies such as PhoneGap, Objective-C, Java, Kotlin, Swift, ReactNative and Flutter. His most successful project has almost 8 million active users a month.
Disclaimer
This article reflects my personal opinions, and it should not be attributed to the view of any my past or present employers.
