Why Xamarin?

As you know there are two primary platforms for mobile development – Apple’s iOS and Google’s Android. Microsoft still leads in the productivity space and so some companies are developing for the #3 platform as well. The difficulty is that apps for each platform are built using different technologies and skill sets. Building apps for Apple devices requires you to use Objective-C or Swift, Android apps are built using Java and Windows apps using one of the languages that target the .NET platform.

The fact that different tools and programming languages need to be used for each platform means that an app has to be built from scratch for each new platform. For many companies this means building a team for each platform, which is not only expensive but makes it unlikely you’ll be able to share any of the code used to build the apps.  It also means you end up with somewhat different apps on each platform.

There have been several attempts to remedy this in the past. A few years ago Facebook announced that HTML5 was the answer – they would develop all of their apps using HTML5 and effectively wrap those apps in shells for each platform.  This would allow them to use one code base and one team for every platform. Unfortunately these apps were slower than native apps.  They also didn’t look like the native apps, they weren’t able to use the tab controls, switches and sliders from each platform.  Users were not happy and Facebook later abandoned this approach.

Which is where Xamarin comes in. Like the HTML5 approach Xamarin allows you to build just one app for multiple platforms using just one programming language and with just one team. Unlike the HTML5 approach, when Xamarin apps are compiled they produce native apps for each platform, so they’re fast. They also replace generic controls (e.g. a tab control) with a platform specific control, so they look like native apps. As a result, users can not tell the difference between apps built with Xamarin and apps built specifically for a platform.

So far, so good. So what else should you know before making a decision?

First of all, how much shared code you’ll have depends on the design decisions you make. There is always a layer of shared application code for things like local data storage, making web calls and proprietary application logic. At the user interface (UI) level you can also choose to share the majority of the code – which means your apps all look pretty similar – or you can choose to build highly customized UIs for each platform while still leveraging the shared application logic.

You will need platform specific code to access some of the native functionality on devices. For example, if you want to allow users to take a photo of themselves you’ll have to use code that is specific for each platform to access the camera. The same would be true for accessing the GPS and the microphone. In some cases features only exist on one platform – like Live Tiles on Windows – and to take advantage of those you’ll write platform specific code. However, all of this platform specific code is still written in just one programming language and in my experience is a small percentage of the overall investment.

You should also be aware that there are not yet as many developers available who have experience building apps with Xamarin as there are who can build platform specific code. I don’t worry too much about this though, for two reasons. One is that Xamarin uses the C# programming language and there are lots and lots of C# developers in the world, so even if they’ve never used Xamarin the learning curve is minimal. Two, Xamarin is growing very quickly, has a pretty strong and growing community with active forums, third party control developers, user groups and the like.

We have developed platform specific apps and Xamarin apps and have found that Xamarin delivers on it’s promise. It allows us to get to market more quickly on multiple platforms at a lower cost, it reduces the cost of ongoing maintenance and we expect that it will only get better.

Planning for Development

I started writing code while I was in high school but my first really big professional endeavor was in software project management.  I was thrown in way over my head – I was twenty-three and I was managing three different multi-million dollar development projects for Ford Motor Company all at the same time as part of my new role at Microsoft Consulting Services.  I had something like thirty people working under my direction and three different customers, each with different priorities and work styles. Given such an immense challenge I don’t think I did too badly but I didn’t do great either and Microsoft eventually decided to scale back the number of projects I was leading.

I learned a lot and as a result of the experience I developed a real passion around learning how to successfully manage complex projects.  Shortly after that project I becomes a certified trainer for the Microsoft Solutions Framework – a project management methodology that Microsoft had developed.  I had a blast occasionally teaching classes about team models, process models, risk management and the like.  Over the years I’ve followed the development of Agile, Scrum and various other homegrown project management methodologies.  My interest in project management coupled with management responsibilities for teams in several different countries led to my interest and specialization in managing distributed teams and the dynamics of teams.

So that’s a little of why I care, but the purpose of this post is to share with you one of my favorite software project management tools.  The various models have all evolved over time – from waterfall processes to “rapid iteration” to buzzwords like “minimum viable product”.  There are pros and cons to each approach and the key to success is knowing what model works best give your particular circumstance.  There are also simple but useful tools or best practices that various models offer up. One of my favorites that has stood the test of time is a simple triangle model that helps everyone get really clear about the both the realities of software project management and the priorities of the folks who are paying the bills.

The idea is simple.  There are three key variables in any development project.  There are the features you want to build, there are the resources (budget, people) you have to do the work and there is the time you have, i.e. yourschedule.  Novices want to answer all of these questions upfront, but the unfortunate reality of project management is that you can only reliably control one of these variables.  To be successful you have to prioritize these variables and decide which is non-negotiable, which is important and which is flexible.


This model is drawn using a triangle with each variable on one side.  You can choose to fix the length of one side of the triangle, but the other sides then have to adjust accordingly.  For example you might say I have $20k to build this app, that’s it, there is simply no more money than that.  You’ve chosen to control the resources available.  You then have to decide what’s second – is it more important to hit a particular date or to have a specific feature set?

The triangle makes it clear that any change – whether it be a new feature, losing a developer or moving up the schedule – requires that other trade-offs be made.  New features usually require either more time, more money or more people.  If you need to make a date but forget to incorporate vacation time into your planning you’re going to have to add resources or cut features.  When someone ignores the need to make trade-offs the quality of the features suffer, the team starts falling apart and the schedule becomes less realistic every day.

None of this is intended to suggest that developers should not be held to commitments, it’s about helping everyone make realistic commitments.  The process of developing an app or a website is full of unknowns.  Will the client like the first design or insist on a second or third pass?  Will the features as they are envisioned really work for users?  When Apple decides all new app submissions must support 64-bit (as they did recently) suddenly developers need another day – that wasn’t a requirement when the project started.  Then of course there is the app submission process itself, wherein some anonymous fellow subjectively decides whether your app is “cool enough” to be approved.

The triangle model is a simple, helpful way to ensure that everyone involved knows what is realistic and what is important.  Coupled with other best practices like early customer feedback and proactive risk management it can help make your projects more successful.

Introduction to Distributed Development

Distributed development is a term used to describe geographically distributed people or teams working on projects together.  It has become a more and more common and accepted way to work as the Internet has made it easier for us to communicate and it will, without a doubt, become even more prevalent.

Having a distributed team can be extraordinarily difficult and many people will dismiss the idea out of hand but there are a lot of potential benefits – the increased diversity of the team, insights into foreign markets, the potential to “follow the sun” to keep work going around the clock and so on.  The pros and cons of distributed development are worthy of long and passionate discussions but for now let’s assume you’re involved in or leading a distributed team.

I’ve spent a lot of time thinking about how to make distributed teams successful because it has been crucial to my success several times in my career.  I’ve developed a model around how to think about what makes distributed teams succeed or fail and there are three different angles I look at.

The first, most obvious thing to look at is Collaboration Tools & Practices.  How do you use email, how do you handle planning and schedules, how do you handle bug tracking and task assignments?  Obviously a physical scrum board with sticky notes doesn’t work when one or more of your team members is an ocean away.  Is there an opportunity in how you schedule work to take advantage of time differences?

What kinds of meetings do you have, at what time and does anybody take notes?  When you have a distributed team you can’t rely on hallway conversations the way co-located teams are wont to do, you have to make a point of including remote team members.  This means scheduling daily meetings to touch base when everyone can be included and not having meetings that only local members of the team can attend.  One thing we found immensely valuable was a rule that if any one person had to dial into a meeting then everybody had to dial into a meeting.

Even more important than process issues though are Team Dynamics.  Who works for who, who has what goals, who are your most influential people and how healthy is the organization in general?  Who has a stake in whether the entire distributed team is successful and who would benefit if it were not?  Distributed development is one of those things a lot of people love to hate and some of those folks will sow discontent at every opportunity.

The good news is that focusing on how to make your distributed team work often helps improve local teams too. When I was managing teams in Europe and China I made a huge investment in building the team that was my direct reports – the leads in each country.  When those four people felt like they were working towards a common higher purpose they did a lot of the work to bring their teams along (and they were happier too).

The third angle to consider is the Division of Work, i.e. what is the purpose of each office and what are the dependencies between the offices. Some companies setup remote offices to address a specific market and some do it to take advantage of cheaper labor.  If there are a lot of dependences between offices it can slow down work and demoralize teams.  On the other hand when leaders go overboard in compartmentalizing work satellite offices often end up with the least important work, which makes them feel unappreciated.

The trick then is to divide up the work in a way that creates positive dependencies between offices.  That’s even harder than it sounds because there is so much to consider – the work that needs to be done, the cost of doing business in each market, the skills and aspirations of people in each office and so on.  It’s complex and it can take several tries to get it right but it’s critical if your distributed team is to succeed in the long run.

There are entire books written about each of these topics but in this introductory post I just wanted to introduce the model.  Even without specific guidance just thinking about your circumstance through the lenses of Collaboration Tools & Processes, Team Dynamics and Division of Work can help you make better choices.