In my previous article we talked about all of the benefits I found when my team decided to design a new feature with the same architecture on both Android and iOS. In this article, I will do the opposite and show you all of the downsides of this approach.
Nothing is perfect and it felt right to share with you not only the number of benefits we had using this approach but also the downsides and the problems we faced. As a bonus, I will also try to give you some tips on how to overcome some of these problems.
In this article, I will tell you about the problems we had and we can put them in 2 different categories: People & Processes problems and Technology problems. You might be surprised to see a bigger focus on the first category compared to the second one. This is something that every developer discovers the more senior he/she becomes. People & Processes problems are usually much harder and delicate to solve than Technology problems (I am generalizing a bit here, I’m sure it’s different at NASA).
Bringing People Onboard
When deciding to develop something with a unified architecture the first issue that you will face is pushback from others. Why? Because not always people are open to change. it’s almost certain that the new way of doing things will require developers from either one platform or in some cases, both platforms, to do things differently. People in your team will certainly ask you “Why should I do things differently? The way we do things now works just fine”.
Unfortunately, I have neither a solution nor a magic formula for you to convince people that the new way of doing things will be better or even good enough just for an experimentation cycle. That is up to you. Just know that convincing people and bringing people on board are key skills for a senior dev and leader, the sooner you start practicing the better.
Too many cooks
The second issue is more subtle and it might not happen if you have a team that works perfectly like a well-oiled machine. I call it the “Too many cooks” issue. When you have too many people working on the same problem it’s hard to align everyone’s views on a solution.
It’s a tricky issue that can happen either in the design phase or in the implementation phase but hopefully not in both phases, I suggest you try and fix it as soon as you recognize that decisions on solutions are not taken in a normal span of time.
Let me tell you what happened to us. I have to say that this time I haven’t seen any issues in the design phase. Sure, there were lots of conversations and back-and-forths but thanks to our manager Hannes Dorfmann, decisions were taken in a timely manner. So the only advice I can give you to avoid problems in the design phase is to have a strong technical leader to point you in the right direction or have a self-organizing team that works like a single unit.
Unfortunately, It didn’t go as smoothly in the implementation phase. We quickly noticed that Pull Requests (PRs) were taking longer than usual to be approved and merged. Inside most of them, you could find long conversations about programming styles and details. We were trying to write code that would match the style and preference of 4 people from 2 different platforms. Let me tell you, that it’s a super hard thing to do, if not impossible. After a couple of weeks, we recognized we had a problem and decided to fix it by defining in a better way the purpose of the cross-platform reviewer. The cross-platform reviewer was there as a second line of defense to make sure that the PR followed the designs that we agreed upon but even more importantly, that the implementation was mostly consistent with the one in the other platform.
Note that I wrote mostly consistent and not exactly the same code because trying to write the same exact code (down to the single constructs) is what was slowing us down too much. I think that if you want the exact same code in the two platforms then you should investigate more on things like cross-platform development. That was it! After this adjustment, the implementation phase went way more nicely.
Long term discipline
The last People problem we will discuss is around long-term discipline. One thing is to set aside a good chunk of time to design and implement a whole feature together and at the same time but what happens after a few months when random improvement tickets start to come up? I’m sure you have also experienced sprints where the goal or scope was slightly different for the two platforms. Maybe one platform has the time to start the improvement ticket and the other one doesn’t. What happens then?
You might think that since the feature was designed together then the devs from one platform can design and implement the feature first, maybe even adding a dev from the other platform as a reviewer to keep the spirit of the cross-platform reviewer and that everything will work just fine.
Be very careful here because you could undo all the hard work you did in the first place using a unified architecture. First of all, chances are that since the ticket is not part of the goal or scope of the other platform’s developer, he/she will not have the time to properly review it. Also since the design and implementation were done mainly on one side, it’s likely that the other developers will not be 100% happy about the result because they have different ideas that they would have pitched, if they would be present at the design phase. Finally, I bet that doing it like this will introduce some slight implementation differences. The same thing happened to us when implementing new tickets 6 months after the release of the original project.
Every time something like this happens you risk adding small differences that could incrementally lead you to an exponential difference of the whole feature. Stay strong and fight for having an aligned sprint goal for both platforms so that you can keep working on the same topics.
Choosing the wrong architecture
There is only one major Technology problem when choosing to develop a feature in a unified way and it’s also the first thing that usually comes to mind: “What if I choose the wrong architecture?”. Let me tell you, this is not as big of a problem as you might think. Let’s explore it a bit.
Choosing an architecture and a design that works for a new feature on two different platforms is not easy. There are lots of moving parts to take into consideration like platform differences, solution complexity, and fit with the requirements. It can happen that you make a mistake and you end up with the wrong design on both apps.
Is it really as bad as it sounds? Kind of, but also not really. Let’s say you somehow managed to implement the feature but you had to suffer through implementing it with a bad design. Congratulation! You just introduced technical debt, welcome to the dark side. This means that long term, you will have to take time from the devs of both platforms to fix it somehow or even refactor it completely.
Do you want to know what is worse than having technical debt on both platforms? Having technical debt only on one platform while the other one is fine. Confused? That’s a good sign.
Having technical debt only on one platform means that in the future only half of your team will be available to implement new stuff while the other half will be busy fixing the errors of the past. And here you go, you created an inconsistent team, a team that will be harder to manage.
We talked at length in the previous article on why inconsistency is bad so I’m not going to repeat myself now. While it might seem counterintuitive, I believe that introducing technical debt on both platforms is better than introducing it only on one. At least if you have technical debt on both platforms it will be easier for you to work with your Product Manager to give the right prioritization and fix it sooner rather than later.
Awareness is key
The point of this article was to show you very transparently that nothing is perfect and every path has its own ups and downs. What is more important though, is to make a decision or take a path knowing the risks that lie ahead. In software development, awareness is key. If you know what might happen, you can prepare for it and mitigate the problems that might come up in the way.
Even though the last two articles were based solely on my own experience, it was quite interesting to see that these exact problems and solutions come up time and time again from different people. The latest example comes from The Pragmatic Engineer himself, Gergely Orosz. He wrote a book called Building Mobile Apps at Scale: 39 Engineering Challenges and there is a chapter on Cross-Platform development. The problems and benefits highlighted there are very similar to the ones found here and in the previous article.
So what do you think? Have you ever faced these problems? How did you solve them? Let me know in the comments down below or tweet at me @_alerecchi
