Thanks for the answer. Overall, you’re making some good points. And I love your engagement here.
But it’s gotta be a no to this still: “Overall, both apps are at feature parity”.
When features like merging payees and putting notes on any transactions still aren’t at parity, and given the length of time they haven’t been, I can only assume never will be. It’s those features which aren’t flashy, but are so core to making the app a great experience which sting the most. Because they feel like they just should be.
Overall thanks but I’m not gonna believe it until I see it.
I agree that it is half the man hours designing a feature on one OS and carrying out the testing and such which enables you to do the same with a different feature on the other OS.
But can I ask when, now or in recent times has there been 2 test ideas running in parallel at once? When one OS had one feature whilst the other OS has had a different feature at the same time for testing? In the scenario you mention…
For example Android now has hiding and sorting pots, so what has been designed for iOS to be tested at the same time?
I feel this reason has been created just to try and justify it not being built yet because I can’t remember this ever being the case. I could be wrong
Bruno suggested they build 2 features at once, one on iOS and one on android. Then once the testing and little niggles have been ironed out and they decide to release it, they build the features on the other OS. Which is fine I might add, I totally get that way of development.
So hiding and sorting pots has been built on android. What has been built on iOS to now be tested at the same time? And has this scenario happened in the past?
I think Bruno is mainly refering to his team during the new nav project and how they (I think potentially a couple of times?) Tried out different ux features on the different OS’ at the same time to get data twice as fast and then later unified the approach.
They weren’t always two different features, sometimes it was one feature done two different ways
Ohhh dear, don’t put performance and non-functional requirements into the same pot as features, that’ll never end well.
And engineers can build things in their spare time, “Imagine if they couldn’t…” well I struggle with this because why on earth would I want a ‘I had some free time so built this thing’ approach in a BANKING app.
And as for ‘not being able to develop at the same time’ that’s fine, but if WE don’t know how the time differences are, then this shouldn’t be an issue that is even visible to users, presuming as you state the time gap is never that long. If you are confident enough to release to A platform, then why not hold a feature until it’s available on both and get the instant ‘ohhh parity’ good feels associated with this (remember, we only KNOW the Hidden Pot feature is Android only for now because you guys told us). If you have two teams available then if you are smart you can get through feedback from users even faster (triage the bugs/feedback, fix x on one platform, y on another, release, recycle the process and fix on the ‘other’ platform, if that makes sense).
The rest of your bullet points are all great start up driven, Agile development principles which has gotten you to a great place up to this point. I reckon another 6 months to a year like this and you’ll have to change tact as your application stack will be too large to approach this way without tipping the ‘parity’ balance one way or another. Fun times ahead.
It does sound like you are on top of this and I like all the thinking and your approach here, I’m not sure the feature sets across platforms are as close as you think mind you but I think this discussion is one to park for a few months and see where we are in Q2 next year.
Perhaps I misunderstand this part of your comment but the impression I got was that you don’t seem to understand Monzo. Monzo really isn’t a bank it’s more of a tech company that operates under a banking licence, this is the approach all silicon valley tech giant’s take to encourage and foster creativity and productivity.
It’s resulted in some pretty neat Little features within the app.
I think that’s okay. Sometimes iOS might need performance work and Android doesn’t so they can focus on new features.
Someone was asking what was built on iOS while Android did Pot hiding, exactly this: we did a bunch of performance improvements on iOS, we also fixed some critical bugs with the new Settings page. Android was free to kick off Pot hiding at the same time.
Gambling block was built by a small group of monzonauts from different teams as a Monzo Time project.
Can we stop pretending that Monzo is a tech company? I know they like to because it leads to higher valuations but let’s get real here. It’s a bank that happens to be good (sometimes) at software development.
Personally I see this aspect as a chance for devs to work on something that isn’t directly related to the current company goals. In reality, at the moment at least, that means we as customers are more likely get features that are useful rather than profitable than if engineers only worked on items relating to the current objectives.
5% of your work-life to develop yourself while also contributing to the company seems like a pretty good deal for all involved tbh.
This thread has just really given me real annoyance with a lot of people and how they see app development as a utopian “platforms should be aligned”, bla bla bla. I work for a rather large commerce app development company and very rarely are things perfectly grand all the time, things get missed, some things need upgraded on Android and not IOS and vice versa. Developers are humans who make mistakes. Sometimes years down the road we realise there are things that should have been done differently. It’s important that people remember coding isn’t always perfect and projects don’t always hit the mark.
Just last week I implemented a massive navigation changes to follow in line with the rest of our apps whereas Android is no where close to getting this done. They’ve (android devs) got their own problems.
