Preface

In this article, I would like to introduce you to our way of working regarding the tech side of our projects. You will learn what is behind our Android Tech Discussion and how we tackle technical challenges by giving each team member a voice. 

Introduction to our team

We are the SPP Apps Android Team. We are a distributed team with six devs, an Engineering Manager located in Poland, and a PM and UX in Sweden.

Even though we are based in different countries, we work very closely together. Technical decisions are made in an open forum where everyone – no matter their seniority level – can share their opinion and impact the decision-making process.

One of our developers holds the Tech Lead role, which can be summarised as

The Tech Lead is a proactive facilitator and driver of continuous improvement rather than a decision-maker. Their primary responsibility is to work within the PM-EM-TL triad, focusing on technical quality. They empower the team to review, renew, and document technical direction and architecture by facilitating discussions, documenting decisions, and pushing for progress.

If you want to learn more about our team, please visit https://www.schibsted.pl/news/meet-the-android-team/.

What is Android Tech Discussion?

Everything revolves around the Android Tech Discussion meeting, where all or most of the team is present to discuss different technical topics, but it’s more of a practice we have been approaching for quite some time. It helps us move our projects’ technical side forward. The meeting is a central point, but there is a process behind it that we follow.

Topics we discuss vary from architectural discussions and ideas sharing to code quality concerns, tools recommendations, etc. We also share issues we face and endeavour to find solutions to enable people to move forward. 

The current team’s tech lead facilitates the Android Tech Discussion.

What is its purpose?

The primary purpose is to have a space for tech discussions with the whole team. We treat it as a forum to speak openly about all tech-related things concerning our team or project. Discussions revolve around important technical topics related to our team or project. Other team-related aspects are covered during retro or other people-oriented meetings. 

What’s also important is that we want to hear everyone’s voice and opinion. During these meetings, we also demo new cool ideas or projects. Moreover, we aim to also align on things that need alignment.

How does it work?

1. Different team members in the live document fill in topics.
2. The person who adds a third topic announces this fact on our shared channel.
3. Tech Lead finds the best time and calls a meeting, inviting all team members.
   • We aim to find time blocks where all team members can join.
4. The meeting happens. Each topic is presented by its author, and then we discuss it.
5. The live document is updated during the meeting by the Tech Lead.
6. The Tech Lead converts all actionable things into JIRA tickets with the tech-discussion label.
7. The tickets are prioritised by TL/EM/PM.
8. If there is a decision or recommendation, the Tech Lead adds it to our project decisions document.

When a critical topic needs to be discussed with the majority of the team, each team member is encouraged to create a separate, ad-hoc Tech Discussion. This way, we don’t wait for three topics and can discuss ideas earlier.

The live document I mentioned is a way to gather ideas and share concerns or topics to discuss. It also serves documentary purposes/discussion logs.

Why is it important?

The most important thing, in my opinion, is that this meeting is to hear everyone’s voice. Everyone is different and perceives the world in another way, so I think it’s crucial to meet up regularly, raise our voices and run various discussions. 

Another thing is to create a safe space to talk about problems. We don’t want to run from them. We try to face them as soon as they emerge and hinder our progress.

Furthermore, we want to be proactive when it comes to solving different problems. There may be a better way to architect things, so feature X is easier. There may be a bug that affects more and more users. That’s why we have Android Tech Discussion, to discuss things upfront, without time pressure.

Examples

How to improve our Android Lint setup?

In one of the recent discussions, we discussed the Android Lint setup in our project. We discussed what could be improved and what is the desired direction we want to go with it. 

Problem

Android Lint setup was not consistent across our modules. Many checks were suppressed. The need was not expressed clearly enough. In addition, the current setup has been leading us to suppress even more checks and was not catching critical errors in our codebase. We decided that we want to have Android Lint configured in a way that captures the most important (for us) issues.

Outcome

We decided to change our Android Lint approach. To disable all rules and then go through each rule from lint and enable only relevant ones for us. There are many lint rules; keeping them all enabled and fixing all the issues is unrealistic. We decided to pair on it, and do everything step by step.

What we did to this day:

• Enabled checkDependencies flag, ref.: https://developer.android.com/reference/tools/gradle-api/7.3/com/android/build/api/dsl/LintOptions?hl=en;
• Created a separate lint GitHub Action workflow;
• Cleaned up build.gradle files from old Lint setups;
• Created a Lint config file with all rules ignored;
• Removed lint.xml config files from modules;
• Adjusted the severity of the Lint rules to our liking. 

We are not there yet, but we made good progress.

Do we want to start using Jetpack Compose?

The hype train! One of our teammates, Rafał, presented a sudoku app written in Jetpack Compose. He wanted to encourage us to start using Jetpack Compose in the production code. He wrote his sudoku app during one of the 10% days* and praised how quickly it took him to do it.

* At Schibsted, we can use 10% of our work time (usually every second Friday) to focus on learning. We call this 10% days.

Idea

As you may know, from the “Meet the SPP Apps Android Team” article, we avoid “hype trains”. That’s why it took some time to decide and find the correct place to experiment with Jetpack Compose.

The idea was to start with a single screen/feature and evaluate it. After some time, the Liveblog feature happened. The Liveblog is like a live football match coverage, with fast real-time news updates in an article, front, and live centres. Content is added to the list from time to time and updated on all clients informing about a new piece of information about a specific topic. You can check one of our live blogs here https://www.aftonbladet.se/nyheter/a/Rr77qd/aftonbladet-direkt.

Outcome

The feature was successfully implemented. Since it was the first thing we implemented in Compose, we haven’t felt any speedups. We had some blockers (bugs) along the way, but we managed to pull it through with some workarounds. The biggest problem was the lack of prior, real-world knowledge and experience, but we trod new ground. Now, with the new experience, we plan to work more with Jetpack Compose, but we decided to carefully assess each new project to reduce surprises as much as possible.

Migration to monorepo

This discussion happened almost a year ago. We talked about moving our internal libraries into modules in our project. For quite some time, we had this setup where some parts of our codebase, which we identified as mature, landed in a separate repository and were served through Maven (internal Artifactory).

Problem

We identified some issues with the approach I mentioned above during the discussion. Mainly:

• People found it hard to debug issues.
• Adding new features was problematic as it was hard to test. publishToMavenLoval was slowing us down.
• It was hindering our ability to prototype quickly.
• We had many version mismatch issues as our project spanned across several repositories.
• Maintenance cost was increasing and increasing.
• It always felt like a part of our codebase.

There was one big con we identified during the discussion. Some people still had MacBooks on Intel… The build times slowly started being annoying, and it will be even slower with more modules.

Solution

We decided to move our internal libraries into our project slowly. Step by step, library by library. As a first step, we discussed the future structure of our modules. We also decided to update our modules’ documentation so things like naming conventions, packages, and setup are reflected “on paper” and clear to everyone. Filip, our Engineering Manager, prioritised buying MacBooks Pro with Apple Silicon for people still on Intel. Then we moved all libraries to our project.

Everyone on the team is thrilled with this change. It made many things simpler. It allowed us to do some recent features and refactorings a lot quicker. And we removed a lot of unused lines of code that were sitting in libraries. 

Summary

Now you know what’s behind Android Tech Discussion, and I hope you can see the value of such a practice in a team. This form may or may not work for your team, but the most important takeaway from this article is to consider having an open team communication forum. This way, people are encouraged to talk about tech debt, obstacles, other problems, and most importantly – how to address them.