Engineering Culture

Our engineering culture enables us to create innovative products that people love while ensuring cybersecurity. We seek to push the boundaries of technology to achieve the new and exciting. We automate and continuously integrate to make our products truly great.

There are 2 teams in our company that need to deliver features every release cycle so they apply Agile principles to their day-to-day work. For them, we apply the Scrum framework. This framework helps people address complex adaptive problems, while productively and creatively delivering products of the highest possible value.

Agile is used for managing software projects and for product or application development. It is an adaptive product development strategy where a cross-functional team works as a unit to reach a common goal within 2-4 weeks (a period known as a Sprint). The framework consists of values, artifacts, roles, ceremonies, rules, and best practices. There are two teams that follow agile principles: Feature OS Team and Communications Team.

There are also 3 teams that don’t apply Agile principles: Long-Term-Support (LTS) Team, Testing & Verification Team, R&D & Innovation Team
Our talented engineers are at the cutting edge of driving our business forward with advancing technology. Building great software is as much about behavior as it is about coding. Our engineers are responsible for more than just coding.
To create excellence requires a commitment to and ownership of the development processes. By committing to this Engineering Culture we can perform better and achieve so much more together.

Coding Standards

• We follow the general Android coding style (default for Android Studio which is listed in Android website)
• We follow the Android Naming convention and naming conventions provided by Java/Kotlin coding standards.
• We format code and file structure using “ctrl + shift + F” everywhere so that the code remains consistent and easy to understand.
• Commit naming – the name must contain the task number and it should briefly explain the implementation or problem it fixes.

Code Reviews

• Each commit must be reviewed by at least 2 other developers before it is tested.
• Each review should be focused on reviewing code quality. If you are reviewing a bug fix the solution should be the simplest one.
• If a bug requires refactoring or a change in design and architecture it should not be changed as a bug fix, but as a planned improvement.
• If a feature implantation is reviewed, the reviewer should make sure he/she knows the implantation logic. Check it covers all the acceptance criteria.
• Code reviews are done at the start of each working day to avoid disrupting other daily activities. Items should spend the minimum possible time in the “Tasks In Review” stage.

Architecture

• We aim for scalable, easy to explain and support architecture that is effective without being over-engineered.
• We follow SOLID principles and Clean Architecture patterns and our decisions are based on that. We meet and present the new plan and if it has any team dependency, the team is asked to join.
• Everyone is welcome to share an opinion regardless of seniority.

Programming Language

• We prefer to use common and proven languages.
• We explore new options but only implement them if the benefit is proven and if maturity is high enough.

Testing

• We follow TDD so each new feature must be tested. Our goal is 100% test coverage of new features.
• Everyone is responsible for the quality and this starts from the development stage.
• If each person tests their own work before handing it over, time is saved down the line.

Build vs. Built

• We prefer to build most of our environment and tools.
• Buying sometimes requires a higher investment than just the price of the tool.
• A key concern is our customers’ privacy and we cannot rely on others to protect that.

Security and Data Privacy

• User privacy is a core goal.
• We do not store private information or take information without first requesting it.
• If we do need user data, we request permission first and ensure the user is aware of what we are using it for.

Definition of Done

• You are not “Done” with the code once it is committed and the task is in Review or Testing.
• You must ensure the reviewer and QA have enough information to test it.
• You are responsible for making sure all the dependencies are taken care of and everyone is notified as needed.
• You are accountable for tracking progress until the end. You must be confident that this task will come back as a new project.