This post has been republished via RSS; it originally appeared at: Microsoft Mobile Engineering - Medium.
Hey there,
I am Chirayu and I’m taking you on the journey of transforming a mere idea into a fully-fledged, efficient feature that requires a compelling tale of innovation. I’m a Software Engineer at Microsoft Teams Mobile and I had the privilege of being part of this remarkable journey from the beginning. This story is not just about the technical process but the innovation, collaboration, and dedication of the teams to overcome challenges creating incredible impact.
It all started when I was feeling too lazy and frustrated to schedule a meeting with folks in my hackathon group chat because I had to go to the meeting scheduler and search everyone by name, add them one by one and then schedule the meeting. Too hectic, isn’t it?
Is being lazy bad? No way, see this quote from the Gates.
So, whenever we are lazy, we have an opportunity to make things easy for ourselves and the world.
The Idea
As described above, if you want to schedule a meeting while chatting in a group, you would have to:
As you can see in the above image, scheduling a meeting from chat takes 8+ steps in Teams Mobile so the idea is to reduce this to just 3 simple steps:
This streamlined approach would save valuable time and simplify the process. This concept sparked the beginning of our journey.
About Microsoft Global Hackathon
Hackathon is a great way for ideation, innovation, collaboration & fun and Microsoft is renowned for its commitment to hackathons, conducting events like CodeFunDo in colleges and the Microsoft Global Hackathon for its employees. After demonstrating the potential of our hack, it was time to go down the road to turn it into a fully-fledged product feature accessible to millions of people on the planet.
R.I.C.E.
The initial phase of transitioning from a hack to a production-ready feature involves discussions with the Product Management team to craft a comprehensive feature specification. This process introduced a new dimension to the idea — a meeting chiclet, a beautiful card sent as a message to all participants upon meeting creation. Once the feature spec is ready, it goes to the backlog list and then it is prioritized with the RICE framework.
RICE Score = (Reach * Impact * Confidence) / Effort
To know more about the framework, head here.
The Triad
Any successful feature requires a harmonious collaboration between the three pillars of software development — design, engineering, and the product. At some companies, a dedicated Project Manager oversees the process, managing communication with stakeholders and clients. In Microsoft, however, the triad — designers, engineers, and product managers — work in tandem to deliver features from start to finish, a testament to our effective teamwork.
UI/UX
User interface and User experience are paramount to any application’s success and that is where our designers come into play. They take care of every minute detail of the feature from aesthetics, native look & feel to user interactions giving a seamless and delightful user experience. Once the design and product specs are complete, they are handed over to the engineering team for implementation.
Estimation
Estimation of cost in any project is very crucial to take calculated bets on the investments the company is making. Believe me, any estimation will most likely turn out to be wrong but “The better you estimate, the better engineer you would become”. Here also, we leverage the planning poker framework which helps us not only in estimates but also provides different perspectives and any risk associated with the task.
Dev Design
Engineering starts and the first thing to do is write a design doc but why?
Dev design doc for any feature must be written so that:
- You do not start implementing in the wrong direction later to realize and change producing waste of efforts
- You don’t get surprises during code reviews
- You think and analyze the pros and cons of multiple approaches
- You get perspectives and inputs from the entire team
- Speed up implementation by having a clear reference throughout
- Facilitates communication with stakeholders
- Helps onboard new members, enhances decision-making, etc.
Design doc can be as detailed, broad, and big as possible but here are some important stuff to cover.
Title: That’s obvious.
List of Stakeholders: Mention everyone with their role in the feature like Designer, PM, Engineer, Manager, Reviewers, etc. so that people can ping anyone in the future for any information required.
The Problem Statement: Why and What of the Feature!
Goals: Specific Goals and Metrics (Product & Engineering) to be achieved.
Non-Goals: These are Nice to have goals but out of scope in current efforts.
Approaches: List all the possible approaches with their trade-offs.
Architecture: Full technical details of the final approach using flow charts, class diagrams, etc. to visualize the code changes involved.
Reusability: We should always leverage the work of others and build new components such that they can be easily re-used.
Dependencies: Upstream and downstream dependencies on different teams & services that are must to be handled before execution.
Refactoring: Sometimes, we need to refactor the existing code with new requirements to make it more scalable. This should be done with care to avoid regressions.
Performance: Analysis of the impact on performance due to the code changes is a must. Loading time, memory usage, resiliency, app size, build time, leaks, crashes, etc. are some key performance metrics.
Test Plan: Good test coverage allows us to achieve more with less time. They help cover edge cases and avoid regressions, eventually speeding up product development. There are three types of automated tests: Unit, Scenario and Integration tests. Apart from these, always take signoff from QA for manual tests because a developer can never be a good tester of his/her own feature.
Telemetry: Proper telemetry helps collect data that helps decide the future of the feature. Also, logging the start and stop of the scenarios helps to monitor the resiliency.
Accessibility: At Microsoft, we give accessibility the highest priority because whatever we create, we want it to be accessible to everyone on the planet. The major parts of accessibility are voiceover, contrast ratio, localization and alternative text for pictures.
Once the design doc is ready and reviewed by the team, it’s time for the easiest thing to do which is coding :P
Bug Bash
After the code is checked in and we get the required sign-offs from the accessibility team, privacy team, quality assurance team, etc. the time will arrive to ship it just to realize after some time you missed something and the customer is reporting a bug :)
To prevent major bugs from reaching the customers, we all sit together to find bugs ourselves first and that’s what we call a bug bash. Thorough logging during feature development simplifies debugging and ensures a smoother journey. Believe me, it’s much more difficult to find the root cause of any problem than fixing it.
Rollouts
Obviously, we can’t directly ship the feature to the world in one go. So, we roll it out first for our team only, then for the company employees and eventually to the world. This staged approach allows us to gather feedback, make improvements, and ensure a seamless user experience. We use a tool known as Experimentation Configuration Service for the same. Also, we use different flavors of app builds for testing purposes (canary -> alpha -> beta -> production).
Impact
As of today, thousands of meetings are created from a group chat or channel daily which is a significant percentage of total meetings scheduled using the Teams Mobile application. Each time you save at least a minute of a person’s time. Imagine the total amount of time of the world we saved by just sitting in a room and deploying a feature. That’s the impact you have in people’s lives by working in companies like Microsoft.
Conclusion
Our journey from a hackathon idea to a production-ready feature exemplifies the power of innovation, collaboration, and dedication. It’s a testament to the commitment of teams working together at Microsoft to make the world a more efficient and user-friendly place. We hope you’ve enjoyed this insight into our journey, and we appreciate your time.
A Journey from Hackathon to Production was originally published in Microsoft Mobile Engineering on Medium, where people are continuing the conversation by highlighting and responding to this story.