Developing Native Mobile Apps In Series: Faster and Better
If you’re on a native mobile development team, writing Android or iOS code, tell me if this process sounds familiar:
- Two devs, one Android and one iOS, receive a virtually identical development ticket for a feature
- They each go off into their respective vacuums and write the code, and (hopefully) the tests
- They go through code reviews and revisions
- They each merge
- The features look and behave (mostly) the same, and the underlying code is wildly different.
- Everyone is happy and takes a three day weekend.
Pretty standard fare when it comes to development of distributed mobile software products.
Why do we do it this way? Well, product owners generally want everything faster and cheaper, so it makes sense to build the same feature in both apps concurrently, right? I mean, building at the same time is faster than building one and then the other… isn’t it?
It’s counterintuitive, but what if building the same thing at the same time is actually the SLOWEST POSSIBLE WAY TO DO IT? You’d feel silly for doing it that way for so long, wouldn’t you? Yeah, me too.
So consider this — what if you did the exact opposite? That’s right. What if you waited until one platform was completely done with a track of work before you started it on the other platform. What would happen?
Sure, product won’t like it, but like most things they don’t like, this would actually be good for them. Here’s why:
Dude, what?
When a developer works through a chunk of work, lots of things have to be figured out; like if any dependencies are missing, if the design has gaps, how it will actually work and how testing can be automated. But, it doesn’t take two developers to figure these things out…
So, while one iOS dev is sorting that all out for one ticket, what if the Android dev— instead of doing to exact same thing, but for Android, and running into the same blockers, and maybe winding up with an inferior result — was working on something else entirely (of similar complexity) that the iOS dev hadn’t even started?
That would mean that both devs would be independently resolving blockers, acquiring dependencies and designing a solution for different things at the same time. Then, when those devs finish their work, and move on to that other thing, all of that discovery work would already be done. All they would need to do is (depending on how different the apps’ architectures are) translate the work of the other platform into another programming language. Even the unit tests would (hopefully) already be written, at least as an example.
Now hear me out: that first developer’s code would have gone through review and revision to arrive at the best version of it; and that could be used to inform development on the other platform. And that second round of development could also act as a double-check on the first platform’s work, potentially turning up bugs or opportunities for optimization. By the time you get to the end of both platforms work, you would have a higher quality end result, and even in the short-term, everything would (theoretically) be faster.
Even if the devs don’t finish at the exact same time, the first developer to start on a ticket would have a huge head start, and would likely have figured out most of the details before the second developer begins. This is still a big win.
Conclusion
The thing that people (you know who I mean) have to realize is that I’m not saying we should stop all development on one platform until the other is done. I’m saying that we should break work up into smaller pieces, and have developers on different platforms work on different pieces, and then copy each other’s work. At the end of the cycle you wind up with at least the same amount of work done in the same time, but at higher quality. But it’s highly likely that you would also save time, and therefore, cost. And everyone can get behind that.