How PugDemy changed the way we approach mobile development (Part 3— The importance of communication)
Welcome to our third part of the three-part series on how we transformed our widely used mobile application to a modern React native stack and helped spread the understanding of the application with the other engineers in our company. In this last article, we’ll be talking about how we managed to create a communication strategy for all the technical changes discussed in the previous two parts, so in case you missed them, it’s recommended to go and read them for having the whole context (Part 1, Part 2)
The new version of the app
After all the processes we’ve discussed in the previous parts of this trilogy of articles, we made it! We could say that we had something similar to the app we planned. Perhaps it’s not exactly the architecture of our dreams but light-years ahead in terms of readability, maintainability, and scalability.
This new version of the Doctors app totally fitted the company’s vision in which all engineers should have the needed context and knowledge to contribute to any mobile projects as these projects were more and more relevant for the overall revenue. With a neat, easy to read, and scalable architecture, the ground was paved and only remained to wait for others to start pushing code to the new platform, doesn’t it? Of course, not. It didn’t take long until we faced the crude reality.
The importance of communication
For the teammates that weren’t fully involved in the whole migration process since the beginning, it was really challenging to grasp the nuances of the new architecture. Dealing with the new Apollo-based store, GraphQL concepts, intensive usage of custom hooks, was simply overwhelming. Too many changes in a relatively short amount of time.
We found ourselves in a place where we had many well-meaning teams that were eager to include the mobile project in their workflows, but at the same time, struggling really hard to do it in an efficient and affordable way according to their most realistic estimations. Does this sound familiar? Yep, it’s pretty much the same scenario we had before starting the migration.
So, does this mean that we’ve wasted our time for the last 6 months? Well… we have now an architecture that we fully understand, almost done from the ground up, with better technology and more importantly, with a mid-term and a long-term vision for it. However, we were missing a piece that we had already considered in the past but we hadn’t given the relevance that it deserves: communication.
PugDemy
Helping others to understand what we made, how and why, so they can get the most of it becomes a key part of every project and it is a huge problem that has many solutions.
One idea for spreading the knowledge about the new architecture could be setting a bunch of demos in which we could show the essentials of the architecture to other engineers as well as the working agreements we came up with. Additionally, we could spend some time creating some graphical support for those demos and share them with our colleagues. This approach is totally fine and might work in most cases.
However, in our case the main challenges we had to face about how to spread the knowledge were the following:
- As I mentioned earlier all mobile-related projects responsibilities had to be managed by the whole company. This means that there wouldn’t be a dedicated team for taking care of mobile tasks and issues. Moreover, it shouldn’t be limited just to the frontend or mobile engineers.
- Only a few of us had any experience in React Native or even in any mobile environment. This will certainly produce a bottleneck in the near future if all the teams decided to include mobile tasks in their quarter goals.
With this in mind and after some quick conversations, we came up with a slightly different strategy for communication. We decided to address the educational project as if it was a complete course, starting from the most essential concepts and including real tasks or internal projects. Some of us were big fans of e-learning platforms like Udemy and that’s how, in a show of creativity, we came up with the PugDemy name for this educational initiative.
I’ll spare you from details about the curriculum of this course, especially because we ended up changing it as the PugDemy sessions were taking place and the feedback started to appear, but I find it interesting to mention how we initially planned those sessions:
- We (optimistically) reserved a spacious meeting room with the hugest TV every 15 days.
- We had to prepare the needed setup for recording both audio of the room and the screen we were sharing. This might prevent the attendants from losing the attention to the session for taking notes, so they can focus just on enjoying the workshop.
- There was just 1 computer in the room where we prepared code examples and a problem to solve as well as all the setup for running a simulator, as in a mob programming session.
- One of us gave a quick introduction to the concepts of the day, namely Javascript fundamentals, functional programming, React, Mobile environments, GraphQL, etc.
- Afterwards, a volunteer or “primary student” as we called them, was elected to manage the computer
- During the whole session, all other students had the imponderable joy of guiding the primary student to solve the problem we created applying any strategy.
After a few sessions using this approach, we learned some key lessons:
- The room we reserved wasn’t as spacious as we thought. This was great news because, despite the fact that there were people struggling to find a place to sit, the initiative itself aroused more interest than we initially expected.
- People enjoyed interacting and discussing the problem to solve or even technical decisions. After each session, we had a bunch of ideas for improving parts of the architecture based on these discussions. This was really intensive for the “primary students” though, sometimes they were the target of an avalanche of ideas as they had the only computer in the room.
- People were keen to apply what they learned in the real mobile task. We even had to create a board “onboarding tasks” in which we created tasks that were uncoupled enough and with the right level of complexity for newcomers. This eventually resulted in pair programming sessions or improvised meetings for solving some particular issues.
As the weeks were going by we started to promote these PugDemy sessions in every coffee meeting or on common Slack channels. We also decided to upload video recordings of all sessions to a common repository for being able to easily share them with anyone in the company. The feedback of this movement was a constant stream of messages from people of both offices willing to attend or just interested in starting with some task after taking a look at the session’s recordings. So we had to add one last upgrade, we started to live stream the PugDemy sessions for other engineers to be able to join from their homes or, more importantly, from our office in Poland. This was especially rewarding for us, something that started as a way of communicating a new architecture ended up being a way of making both offices work together, shortening the distances and smoothing the way for what was about to come.
And suddenly…the pandemic
Some weeks before the pandemic reached us, the company decided to send us to our homes as a precautionary measure. We’ve been used to working altogether in the same office and the company culture encourages coffee meetings and team activities. So, the pandemic happened to be a huge challenge for us in terms of communication and team building. Like many companies around the world, we had to change and embrace the new scenario. PugDemy needed to evolve to something different.
The good part was that, when this situation appeared, we already had a lot of people already onboarded or, at least, we had done a lot of work for increasing the mobile awareness among all engineers in the company. The ball had to keep rolling, so we naturally started to put in practice some techniques that might work better in a remote environment. Some of these techniques such as pair and mob programming sessions or creating squads for specific purposes are well known and common in other areas in Docplanner. These practices found their place and started to appear and grow in mobile now that we had more than just a few engineers with the needed context.
On top of that, the product teams started to include tasks for mobile in their quarter goals, trusting their team but also having the PugDemy community as a safety net. This gave the right amount of push and confidence for the mobile projects to reach the next level of maturity.
Finally, more engineer joined the company during these last months bringing with them more experiences from other projects and a new and fresh point of view from which the mobile projects are nurturing
Conclusion
Through this three-part series, we wanted to share a journey of a couple of years of work. We’ve discussed how we took tons of decisions and made deep changes that directly affect other areas of the company, we also made mistakes and changed our minds hundreds of times, especially during the early stages of this project. We’re still walking this path as it grows but we already have a couple of key learnings in our backpacks.
One of these lessons is also an assumption we’ve made during this series, the company commitment is essential. As I mentioned earlier, we took decisions, made changes, errors and corrections with an application that was already on production for thousands of active users. This was possible basically because we had the needed time, space, and freedom for testing technologies, making proof of concepts, using paid services if we needed, and, ultimately, take advantage of any resource we might need from the company. We had also to explain what we were doing from time to time, of course, but there weren’t constraints of any kind for us to explore the best solution. This provided us with the needed confidence and motivation for tackling such an overwhelming project.
One last lesson we learned during this journey is that every big change must come with a big knowledge sharing strategy. No matter how smart, complex or complete your engineering solution is, you’ll need to create an educational strategy for it and put in the same amount of effort and, probably, twice the time spent for the purely technical part. Arguably, this effort could be reduced to writing good enough documentation and publishing it for whoever is interested. But, according to our experience, it is way more rewarding and durable to go one step further and have an active communication strategy that eventually will grow into a trusted and reliable community.
Read with the series
Part 3 — The Communication
If you enjoyed this post and this series of articles, please hit the clap button below and follow us on Facebook, Twitter, and LinkedIn.
