The Definition of Done (DoD) for Xamarin Developers

A DoD or Definition of Done is a software development term, the term is common in many agile teams and it has origins in SCRUM. The basic idea is that a team has a shared understanding of what defines a task as Done. What a project manager might foresee as ‘Done’ can be different to a developer or a customer. At XAM Consulting we deliver high quality solutions for our customers and therefore a solid DoD is essential. It’s important all developers understand that just because they’ve made a code change this does not mean it’s done.

We’ve recently revised our Definition of Done and thought we would share it because it’s a good marker on what it means to be ‘Done’ as a Xamarin developer.

Note* This is only a checklist for what’s done as a developer, it’s not the complete software lifecycle, in order for this to be successful we also need to follow modern software engineering techniques including gitflow, CI and TestCloud Testing.

So here I present… The Definition of Done (DoD) for Xamarin developers. (This DoD could also apply for Mobile Developers or Cross Platform developers)

Code respects .NET Coding Guidelines
We follow .NET coding guidelines outlined here – https://github.com/dennisdoomen/CSharpGuidelines

Code respects XAM Consulting’s Code Quality and Architecture Guidelines
We’ve not published this in the public domain (yet) but in summary we follow industry best practices for code quality. Our code bases are designed to be maintainable in the long term. Here’s a short summary:

  • Code is Loosely Coupled
  • Code has High Cohesion
  • Code makes use of OOP (avoiding pitfalls with inheritance, prefer composition over inheritance)
  • Interface Driven Development – programming to small interfaces
  • Classes are small
  • Methods are small
  • Code follows SOLID Principles
  • Use and understand design patterns
  • Make use of Reactive patterns

Tested on all target platforms
As our solutions are cross platform it’s essential that all code modifications are tested on all target platforms. If you test on a single platform it’s not done.

Tested on variety of screen sizes
It’s easy to code a UI for a single screen size but much harder to have it work on multiple sizes, especially smaller devices. All code modifications must be tested on different screen sizes.

Tested on a variety of physical devices
Real devices behave differently to simulators in many situations. All code modifications must be tested on a variety of devices, internally at XAM Consulting we have a good variety of different physical devices for internal testing before we go into TestCloud.

All possible side effects tested in system
If you make modification in a complex system it’s essential that you test for any possible side effects.

Tested in Release Mode
Applications can behave much different in Debug mode then Release. We need to make sure we’re testing the application in a release mode.

Application must handle intermittent connections
Mobile devices have transient connections, there needs to be a strategy for handling these types of connections.

Units Tests
Unit tests are an essential component of a high quality codebase. If it doesn’t have unit tests it’s not done.

UITests developed covering features
Xamarin TestCloud is a great tool, it’s saved us (from production issues) a number of time. We now have UITests and CI with (TestCloud) on all of our projects.

Peer reviewed code
This is a no brainer, peer reviewed code is essential. We made this a part of our lifecycle using gitflow.

Peer reviewed for end-user acceptance
It’s important that not only the code is reviewed we also need to ensure that the problem is well understood. It’s important that two or more people discuss and understand the issue. Once understood the developers must both test the solution will meet the user acceptance criteria.

Issues must be reproduced
If you don’t reproduce an issue it cannot be confirmed as solved. The issue that is reproduced must be exactly the same as the issue that’s reported, otherwise there might be two issues.

 

Essentially, the goal is to have no issues when shipped into a UAT environment. If you ship a issue into UAT you need to review why that issues went into UAT.

At XAM Consulting it’s our commitment to ship world class apps and I hope that you can also make the effort.

 

Leave a Reply