0

I recently started a new position as an iOS dev at this new startup. I know how to create fairly complex applications using Apple's frameworks UIKit/SwiftUI etc...

I have always heard about RxSwift/RxCocoa but never actually did anything with them till I joined the company where they're currently moving from classic UIKit to RxSwift/RxCocoa, which was not a problem for me, since I thought it's something new and I like learning new things. I read a book or two and looked as some OS examples and then started implementing things on my own. However, I am a person who always like to know why a certain technical decision was made. Is it beneficial or are we doing it because it's the cool new thing? It didn't take me much time to realize that it just didn't make sense.

The application is fairly small at this point. RxSwift adds a huge amount of unnecessary complexity. Requires a completely different mindset to program in, test, and "maintain". I find that given our current state and even future state of the application it requires more work (unnecessary work) to do something which can be done in a simpler manner in classic UIKit. RxSwift/RxCocoa as far as I can see simply tries to replace most of the SDK already provided by Apple.

In addition, the architecture of the application is MVVM similar to what you find in Android apps. The only "minor" difference is that Android's SDK has a lot of what makes MVVM MVVM supported and baked into the SDK (note: I understand MVVM can be implemented regardless of SDK/platform, however, it's being implemented like it's on Android). And I found out that this transition in arch and the use of Rx was made by the engineering manager who is an Android developer.

How do I talk to him and convince/show him that this might not be the best approach. I've asked before about the reason but I got nothing other than basically "this is how we do it... it's clean... it's etc...), without an actual reasonable answer to how it's beneficial to the project.

EDIT 1: Getting into too much details about the tech in question might have confused people.

The idea regardless of tech is that the tech manager decided that our team who works using different tech / different way of working from what he's experienced with, should follow the same way he's experienced with. Which may not be the best since as mentioned there are a lot other much simpler and easier ways of getting the job done with a lot less effort and is easier to maintain.

K.A.Q
  • 101
  • 1
  • 5
    This question would be better without the middle two paragraphs describing UIKit, MVVM, etc. The vast majority of users here don't know any of that stuff and the question shouldn't be about convincing us anyway. – jcm Jun 17 '22 at 23:47
  • Ask nicely if the architect will explain to you why it was chosen. There is very likely important things you are unaware of. Then reconsider. You might be wrong. – Thorbjørn Ravn Andersen Jun 18 '22 at 05:56
  • 1
    Isn't the question title a little premature? I can't tell since I don't know the technologies in question, but judging from some of the answers, it's not necessarily clear that your manager's decision is a bad one. – gidds Jun 18 '22 at 11:26
  • I have edited the question and hopefully it's clearer now. – K.A.Q Jun 18 '22 at 14:08

5 Answers5

6

Keep talking with your engineering manager on this subject. However, stop trying to change his mind and start trying to change yours.

Engineering managers and technical leads always have reasons for their toolset and platform decision. Usually these are well-reasoned and supportable good reasons. When you feel uncomfortable about such choices, you should keep questioning and investigating until you understand the thinking behind each decision.

When such a choice turns out to be wrong, you are still going to have to understand the reasoning behind it before you can hope to argue against it.

And when a choice turns out to be right, you will eventually come to understand why. But only if you are willing to change your mind instead of your manager's.

In the case you describe, it looks like your EM is trying for maximum portability. Either your management wants to keep the option of porting to potential future platforms, or they simply do not trust either Apple or Android to remain stable enough.

How long do you expect the application to stay on the market? Is that longer or shorter than the time that UIKit has been available? What came before UIKit, and how long was that around?

The application is small now. How big do you think it will get? How many developers will need to co-ordinate its maintenance and enhancement?

But enough guessing. Keep talking to your EM. He should have convinced you by now that he knows what he's doing. Just be sure you're not the one preventing him from doing so.

A. I. Breveleri
  • 19,293
  • 9
  • 37
  • 63
0

You've already set your point. You think it adds unnecessary complexity. Explain it this way to your engineering manager, stating your concerns. Clarify that time to market is also an important value. I've seen uncountable times software architects getting crazy with microservice architectures for a MVP of an app that could work with a properly coded monolith, and then they spend months going through the crazy architecture that anyway will get outdated.

State clearly that you are not acquainted with the technology and this will take you slightly longer than with other tecnologies. Be able to provide ballpark estimates at a full project scale.

Once you've set your points, ultimately it's your boss, and the one who responds for the performance of the team and the delivery of the projects. You are just a developer, and it's not your duty to convince your manager to change his mind (hierarchy exists for a reason). You have provided with your best professional judgement and opinion, and it's up to your manager to take it or disregard it. In the latter case, you are best suited learning RxSwift and seeing how the proejct goes.

Perhaps you find out it wasn't such a bad idea. Or your manager finds out you were right. In either case, the responsibility in the decision was not yours.

Marc S
  • 2,045
  • 7
  • 17
0

The application is fairly small at this point. RxSwift adds a huge amount of unnecessary complexity.

One simple question: do you think it is the company goal to stay fairly small?

If they wanted the app to stay small, what would they need you for? Aren't you supposed to add to the app and make it grow?

It's always good to plan for the future. It seems your manager did that. Good for you, good for him and good for the company.

nvoigt
  • 138,739
  • 73
  • 318
  • 416
  • I understand that. However, even if the application grows bigger, my point is this will add even more complexity and more time to maintain especially as it grows bigger. I have previously worked on an app that's at least 10 times the size of this and it was extremely easy to add/modify/remove features/code due to it's simple yet robust design without needing any external tools/libraries. – K.A.Q Jun 18 '22 at 14:08
0

Time might prove you correct, or time may prove you wrong. Hindsight is very accurate and either you or your manager will be justified.

BUT, at this point in time you do not have the responsibility for the decision. You do have to provide your best work even though you think the are proceeding incorrectly. Of course you could leave but that is a different question.

Solar Mike
  • 17,891
  • 9
  • 48
  • 59
-3

Didn’t get one job a few years ago because I never learned RxSwift. Was a good company as well, nice to see your product advertised on TV. If they want to use this, that’s up to the company. Close to impossible to change their mind.

Right now there are plenty of jobs around. Find the one that suits you best. Or learn RxSwift, it won’t hurt you or your career.

gnasher729
  • 169,032
  • 78
  • 316
  • 508