Working on a Software Application having Millions of Users.
Working as an iOS engineer on an application having more than a 10 Million plus user base.
As we all know we work in a very diverse industry, where the criteria of development are different for every organization. Every organization follows its own handbook and its choice of SDLC to develop and move forward with any particular software product.
In this article, I will share my experience with the development team I work in & will break down how a high-potential product delivers high-quality features to the product team and finally into production.
Working on a software product with a high user engagement has been very different for me than working on a lower consumer base.
It’s been around 1 year I started working on an Application having more than
10M+ user-base as an iOS Engineer. Usually, there are multiple development teams for a big product as also in my case.
Product & Sprint Planning:
Usually, the product team is always ahead of the development team with new features & requirements, if the development team is working on sprint no 1, the product team usually has already decided on additional features that would cover up the next 5–10 sprints or even more than that.
Based on the development team's capacity, the Team Manager will pick up the features to be included in the Sprint.
Development:
After the sprint is locked and sprint understanding has been transferred to the particular feature team, development is started.
We as software engineers play the most important role in converting raw requirements into highly usable features that goes out as a final product for the end-user.
Development always requires a clear understanding of the features that are part of the Sprint.
Product knowledge plays an essential part in the phase of development for the developer, the more developer knows about the scope of the product and has more technical knowledge of it, there is always higher the chance of delivering a great feature.
With products of this scale, you usually have to be very alert while writing code, because usually, your code interacts with a lot of old & pre-existing features that can always have a high chance of breaking in production.
So you always have to run your feature multiple times to make sure everything else is working fine and tests always pass.
Nevertheless, you become habitual of it doing it every day.
Every feature has a priority and a delivery date to go into QA, based on that every developer knows what's on the priority list.
After a particular feature is built, both the development teams from different platforms owning that particular feature test it closely before giving it to the internal QA team. The chances of bugs already go down.
Testers:
As soon as development is started the QA team, on the other hand, starts writing test cases for the sprint, which effectively helps them to save time and they can easily execute the test cases when any feature comes under testing by the development team.
Fixing Issues:
Issues coming from the specific features are usually assigned to the feature owner(developer) as he has better knowledge of it.
The developer fixes it quickly and it again goes into QA and usually after confirmation the feature is cleared by the QA.
The cycle continues, this process is applied to every feature until the whole sprint is cleared by the QA making sure the Quality of every feature is at its best.
Priority Fix:
Sometimes you are assigned an issue that was written years ago and it's now on Priority, in these conditions you can never just go in and change the code assuming it will work fine, sometimes your small fix can cause a lot of trouble. So it's always best to run that code multiple times concerning how unit tests were written.
UAT Team:
As the Managers, the development, and the QA team make sure that everything is covered, we then send the complete features that were covered in the sprint to the UAT team.
Sign Off:
If everything is fine for the product team they sign off the sprint and after that, the process of the feature going into production starts.
And then other teams take over the particular feature.
Hyper-Care
It’s the period of time immediately following a system Go Live where an elevated level of support is available to ensure the seamless adoption of a new system.
After the launch of a new module, feature, or a whole new app the software teams go into hypercar by providing extra support to their users. This additional support helps new and existing customers understand how to use the newly released feature or module.
So that’s basically it!!
Just an overview of how great teams always put in a lot of effort for the users to give them a high-quality product. Usually there
Please leave a comment if you like the article or have any questions in any regard related to the article.
Until next time.
Thank you.
Sheeraz Ahmed
