App Development

Xamarin development best practices: team structure

team of iOS, Android and Xamarin developers collaborating around a table

One of the most marketed features of Xamarin development is the benefit of the shared code in the Portable Class Library (PCL). As we mentioned in Jeff Ward’s previous blog post:

“While issues relating to portability can arise, code sharing between iOS and Android is pretty uncomplicated and simple. Networking, business logic, parsing logic (including error handling), navigation logic, models, and view models are shared between all versions of the app. What this means is there are no discrepancies in functionality between platforms, resulting in similar operation and easier bug hunts. In fact, of all the bugs reported in our Xamarin apps only a small handful are platform specific, and this means they only need to be fixed in a single place by one person at a time (instead of many different locations).”

As Xamarin becomes an ever more popular solution with our clients, we’ve had increased opportunity to refine our development practices to make sure we are taking full advantage of the benefits it offers. This shared code structure lends itself to improvements not only in how well and how fast we can code, but also in how we form our project teams.

When assigning software engineers to projects we traditionally do so on a platform basis: one each iOS and Android for small projects, or two each iOS and Android for medium size projects. For small to medium size projects using Xamarin, we’ve had tremendous success utilizing a three developer team to streamline our process and realize as much as a 30% savings in development time.

Our optimal team consists of three members - one iOS platform expert, one Android platform expert, and one software engineer whose responsibility is the code shared between the two. We’ve found this separation of duties to be optimal for the following reasons:

Allows our team to really “get into the groove” Consider the analogy of an old single blade walking plow. With PCL (shared) code development leading the way building the data layer and writing unit tests, the platform developers follow immediately behind, locked into the related feature work, keeping their attention squarely on the details of the user’s interaction with the application. The shared code often requires more work, which leaves the platform devs more time to focus on platform specific polish and behavior. Communication is extremely important for this to work correctly. The team must ensure that PCL development and changes are understood and approved by everybody on the team. Generally we do this as part of the standard Agile process meetings, but we maintain open discussions during the work day and over Slack as well. In addition to being co-located, our project teams sit together in group spaces for the life of a project which facilitates this communication.

Creation and assignment of stories & defects When creating user stories, our project manager splits a typical feature into three separate stories: one for PCL and one for each platform. Network/data/logic layers as well as all strings are assigned to PCL. UI stories and other platform specific behavior like file system interaction are assigned per platform. For consistency, requirements and test cases are written once and linked to the three stories. When the feature is ready for testing, QA determines if a defect is shared across platforms (like a button label is incorrect) and assigns the issue to the PCL engineer or, if it only appears on one platform, then the issue is assigned to the platform engineer. In cases where it’s uncertain, our team assigns it to the PCL engineer and it’s up to that member to reassign if needed.

Team efficiencies Encapsulating each developer’s responsibility on the project greatly reduces merge conflicts and the likelihood of stepping on one another’s toes. Additionally our PCL teammate can jump ahead and find any risks like incomplete APIs or other issues before they block feature work.

Improved feature estimation Asking an Android or iOS developer to estimate the development time for a Xamarin project can be difficult. Breaking the project down by PCL and platform gives more clarity to the scope of tasks and makes it easier for engineers to give an accurate assessment of the time it would take to build their individual components.

In summary we feel this three-pronged development effort helps us hit the sweet spot of speedy and efficient development and really utilize the advantages of the Xamarin platform. And we’d love to have a conversation to learn how we can help you with your next Xamarin project!