> If "time to ship" is actually important, than why do most companies go to the work of making three separate codebases for their applications - Android, iOS, and web?
In my experience at a FANG company, it turns out that building and supporting three separate code bases is (counterintuitively) faster and more productive than a unified code base.
We took a stab at this using Reactive Native and C++. It’s been a couple years at least since we did this, and so disclaimer: this might not be the case today. I am also no longer with that company.
The developers hated using RN. In 80% of the use cases, everything worked ok. The other 20% of the use cases consumed 90% of the teams time, and we effectively had to hire engineers who were experts in iOS, android, AND now react native. Meanwhile, the total amount of time to launch a new feature did not decrease.
Our C++ path had its own problems. Building dependencies across different architectures was a nightmare at times. My organization didn’t really have C++ developers. Surprisingly this didn’t really slow us down, and we quickly worked around the learning curve. This worked for us because we weren’t writing low level system code but just business logic.
When it came time to integrate into our iOS applications and several android applications, we again ran into build issues. We had many copy and pasted CMake scripts, which no one really understood and no one really wanted to maintain and own. This was frustrating enough that we experienced significant turnover, and we lost very valuable teammates.
In hindsight, we took both of these paths inorganically. These decisions were made by senior staff engineers and upper level management. It pissed off a lot of developers and lead to a lot of turnover. I have friends at that company, and they are again thinking about going back in the same direction.
> My organization didn’t really have C++ developers. Surprisingly this didn’t really slow us down
> When it came time to integrate into our iOS applications and several android applications, we again ran into build issues. We had many copy and pasted CMake scripts, which no one really understood and no one really wanted to maintain and own
Seems like the lack of C++ developers did slow you down. C++ developers knows how to make proper build scripts and wrap platform specific code to make their codebases portable.
Sure. What I was trying to convey was that we were able to quickly write business logic and test the logic for functional correctness. We had initially assumed that writing sleep plus pluswas going to be very difficult, big prone, and tedious. Surprisingly this didn’t slow us down. But building and integrating was extremely expensive.
Yeah, C++ isn't really that hard to write if you are experienced with unit testing in other languages. The big hurdle comes from managing the build system since it integrates with the language and there is no default way to just build and run things, this is very different from most modern programming languages. Which is why for team projects you shouldn't use C++ unless you have a person experienced with C++ who can set that up and manage it properly.
In my experience at a FANG company, it turns out that building and supporting three separate code bases is (counterintuitively) faster and more productive than a unified code base.
We took a stab at this using Reactive Native and C++. It’s been a couple years at least since we did this, and so disclaimer: this might not be the case today. I am also no longer with that company.
The developers hated using RN. In 80% of the use cases, everything worked ok. The other 20% of the use cases consumed 90% of the teams time, and we effectively had to hire engineers who were experts in iOS, android, AND now react native. Meanwhile, the total amount of time to launch a new feature did not decrease.
Our C++ path had its own problems. Building dependencies across different architectures was a nightmare at times. My organization didn’t really have C++ developers. Surprisingly this didn’t really slow us down, and we quickly worked around the learning curve. This worked for us because we weren’t writing low level system code but just business logic.
When it came time to integrate into our iOS applications and several android applications, we again ran into build issues. We had many copy and pasted CMake scripts, which no one really understood and no one really wanted to maintain and own. This was frustrating enough that we experienced significant turnover, and we lost very valuable teammates.
In hindsight, we took both of these paths inorganically. These decisions were made by senior staff engineers and upper level management. It pissed off a lot of developers and lead to a lot of turnover. I have friends at that company, and they are again thinking about going back in the same direction.