Sharing best practices for Android, iOS, and Windows apps
Working at a consultancy company with an open culture and over 200 employees has its benefits over being a lone-wolf freelancer or a small startup. Whenever you’re stuck on some issue, it’s very easy to reach out to dozens of highly competent developers. One of them is sure to have answer to your problem.
But great software developers don’t just overcome issues; they constantly learn new things to keep up with their fast-paced industry and even lead it at times. At Futurice we work on hundreds of different projects, so we get to share practices among a rich variety of cases and technologies. This isn't true for every type of workplace: a product-centric company, for instance, might have only a handful of software products and a more limited technology set.
Our tool of choice for daily communication is Flowdock. e have flows for dozens of topics ranging from individual technologies to an all-company “god flow”. Over time, we have discovered some practices which we agree are good for mobile development.
We decided to write down our advice, so new developers can understand our way of working and more experienced folks can learn "that new trick" they hadn't known about. We call these our "best practices READMEs". These repositories are publicly available on GitHub, because why not? Sharing our discoveries with the world is the least we can do to show appreciation for the benefits we have gained from open source tools and the larger developer community.
We currently have best practice documents for Android, iOS, and Windows. In these documents we list hints and tips, describe recommended architectures, good libraries, good conventions, etc. Notice that the approaches in the repos are somewhat different. We would love to hear some feedback on the strengths and weaknesses of the different approaches.
Not only are we delivering a document to the world, but we actively maintain it as part of our profession. It often becomes a two-way street, where we receive contributions from the larger developer community too, such as critical discussion on questionable advice. Some people even translated our content to Japanese, Korean, and Chinese!
These community contributions are very important to us. They challenge us to keep our internal development practices on par with the world's top expertise. Feel free to open issues on practices you don't agree with, or to engage in discussions on topics you'd like to see a best practice formulated on!
- Andre MedeirosUser Interface Engineer