PART 3: Optimize
Optimization 15%
Agile Process 8%
Modest Execution 6%
Project Management Expertise 5%
34% of the problem is here, according to Standish CHAOS Report
Tip #10: Continuous Integration & Analytics from DAY ONE
If you aren’t using Microsoft AppCenter for your Xamarin App, you need to go take a look. Basically, it is a one-stop-shop for a gaggle of amazing tools.
Get your simple, debug, simulator, master/dev branch CI pipeline for all of the platforms you will support, set up and successfully building – in Azure DevOps or AppCenter or wherever – on DAY ONE of development. The build will more likely succeed on an empty solution, out of the gate. Now you are starting from a state in which your project was already building successfully, when the build now breaks, it is easier to figure out what the problem is.
Don’t worry about build minutes – build on every push – your time is more important!
Microsoft AppCenter can generate the build badge code for you, you just cut and paste from your build config. Wire up your build badges to a central place on DAY ONE – maybe in the readme of your git repo – so you can quickly see if all of your platforms are successfully building. This also allows you to quickly see if you should or should not fetch and pull the latest into your local solution.
Wire up analytics on day one and as you write code, make a habit of adding Analytics as you go – don’t leave this until the end of the project! To make these analytics as useful as possible, think about how they will be crunched…
- Keep the event name short and sweet.
- Keep any details in the string dictionary (or whatever your analytics platform uses).
- Invest some time in working with this data in Application Insights so you get the most out of the data you are collecting. It is a powerful tool!
In the above example, had I included the userEmail in the event name, the analytics would be relatively unusable and messy. This way, I can very quickly tell – in the last 7 days, I have had 9 user sessions, with a total of 56 login events. The following three users logged in… etc.
Tip #11: Monitor Crashes from DAY ONE
Tracking down crashes takes time and often pulls in multiple developers. Wire up Crash reporting on DAY ONE of development.
If you are the team lead, keep your eye on crash groups to see if anyone on your team is chasing their tail.
Having this history allows you to identify patterns. Each of these represent a potentially frustrated, spinning developer.
Spot check this in the first 10 minutes/last 10 minutes of each day.
Keep tabs on your crashes with notes and mark solved crashes Open – Closed – Ignored. This gives you a clean history of your apps crashes in case the pop up again.
Tip #12: CodeMaid – Avoid Merge Conflicts
Botched Merges Cause Delays – often involving multiple developers! I put my foot down and require everyone on my team to use CodeMaid because it automatically organizes and cleans our code on save. It is a Visual Studio Extension for PC only right now.
- Agree on an auto code-cleaning tool that your whole dev team will use
- Auto Clean on Save
- Auto Reorganize on Save
- Alphabetize members of the same group
Tip #13: Identify the Hard Parts and TimeBox POC
- POC = Proof of Concept
- Identify any specific technical challenges and/or high risk tasks
- Allow yourself a specific amount of time to research and/or create a POC
- At the end of that period of time, find a team member and talk about your findings and decide what to do next
- Try not to ‘spin’ on a particular problem, by yourself, for too long
Tip #14: Build an MVP with “Good Bones”
The use of an MVP strategy is widely used and applauded in the Standish CHAOs report.
- MVP = Minimum Viable Product
- Include just enough features to satisfy the user’s base needs without investing in a long development cycle.
- This allows for the collection of feedback from users to decide what direction the development to go next.
- Build this base functionality MVP with a good architecture upon which you will continue to build.
In other words:
DO NOT confuse a POC (Proof of Concept) with an MVP (Minimum Viable Product)!
DO NOT count on ‘reworking’ the base architecture after the MVP is complete!
Tip #15: Push the Business Rules Back
Often mobile projects include Web and WebAPI aspects. As WASM gains popularity, we, as Xamarin Architects, are going to move more and more towards sharing models and business rules between ALL of these pieces. It is going to save us an incredible amount of dev and QA time. To get the most out of these architectures, get in the habit of isolating your business rules into a project that can be used in more than just your Xamarin app.
- Aim to write your views and view models such that at least the major business rules are pushed further back in the architecture
- This allows you to more easily share the code
- This allows you to write meaningful unit tests
- Make a separate project in your solution for business rules on day one
- Make a separate project in your solution for your business rule tests
Tip #16: Battle Context Switching
Try to reduce how often you context switch – Start out by being aware of how often you context switch during the course of a day or a week
- Keep a ToDo list of your miscellaneous tasks that should take less than 15 minutes. Try to knock one of these off of the list at the beginning of the day, maybe before stand-up, or perhaps right after lunch.
- Figure out WHEN the most productive code-writing block of time lands in your day. Everyone is different. Block this period of time out on your calendar as often as you can. Look at your past check-ins to identify your most productive time of day. Pair up challenging tasks or user stories with these prime productivity blocks of time.
- If you are responsible for supporting existing software and writing new software, get a ticketing system for service requests.
- Silence your phone. Earbuds. Noise cancelling earphones. Sign on your door. Set your Skype/Slack/Discord status as BUSY.
Try to make it easy to recover from Context switching – Sometimes listening to the same type of music or the same album or song over and over can help get you in the ‘state of flow’ faster after a disruption.
Tip #17: Anticipate Apple Developer Delays
- Anticipate and Expect delays related to the Apple Developer Membership Program
- The Apple Developer Membership program agreements often get stuck in the legal departments of mid to large companies.
- Begin the process of acquiring this early – don’t leave it until the last minute.
- Apple requires a Dunn & Bradstreet (D&B) number, many companies want to run this through their finance department and this sometimes causes further delays.
- DO NOT use this as an excuse to delay iOS dev or testing on your app.
- Use the simulator or use/acquire your own membership and dev provisioning profile while they get things figured out
Tip #18: Anticipate iTunes Submission Delays
I suspect the iTunes store is allergic to approving an app on the very first try.
I have been rejected on two recent (2019) apps for the following reason: “The Usefulness of your app is limited by the minimal amount of content or features it includes.” So, submitting MVPs too early may not be useful. Submitting too early might be a waste, waiting until the last minute can cause major delays.
Work with stakeholders early on in the project to figure out how the app should be presented in the store. If this metadata needs to be modified, it requires a human moderated review, even if the archived build has not changed. This can lead to you pulling the app from the store temporarily while the metadata is approved by Apple.
If the app is approved, it doesn’t have to be released. You can set the app to ‘manual release’ in iTunes Connect
Tip #19: Visual Studio Task List
Use a //TODO, //NOTE, //HACK, //UNDONE, etc or create your own. You can also modify the priority. Then, have everyone on your team dock the TaskList in Visual Studio.
Check these before you do releases to see if there are any outstanding bits that need attention!
Tip #20: First 10/Last 10 Minutes
Keep a notebook next to your keyboard. When something pops in your head, don’t distract yourself from coding – jot it down.
In the First 10 minutes of each day
- Check builds and crash reports – this allows you to bring up any problems in stand up
- Review notebook
In the Last 10 minutes of each day
- “Scan the horizon” for what can go wrong, calculate probability and mitigate
- Update your User Stories and Tasks
- Review notebook
Capitalizing on the first and last 10 minutes of the day is an attempt to avoid distractions and context switching.
Try to complete or delegate those notes/action items at the end/beginning of each sprint. If an item needs to linger into the next sprint, consider sharing it with the team and turning them into an ‘Issue’ in Jira/AzureDevOps/TFS etc.
Bring this notebook to sit-down meetings. Even if you don’t feel like you are going to use it, people feel better when they see you write it down. Think waiter/waitress at a restaurant. Don’t you feel nervous when your waiter/waitress doesn’t write down your order?
Don’t expect your project manager/BA to take notes and distribute action items.
RocketBook notebooks are amazing.
Tip #21: Avoid Late Summer Public Releases
In summer, scan the horizon for upcoming info from Android and iOS on their new releases. Try not to do a public release in late summer without scheduling a bit of time to do some due diligence on any changes to either OS that may have some affect on your app.
Recent Examples:
- iOS authentication facial recognition
- New bezels, notches, etc.
- Changes in location device permissions
Tip #22: Keep Build Numbers in Sync
- For the sake of sanity, keep your iOS, UWP and Android versions in sync.
- Always TAG your repo commits in Git when you do a release
- Always make a release branch in Azure Dev Ops/TFS when you make a release – be ready for those high-pressure hot fixes!
- Be aware that if you use a CI/CD script to increment the build, that version number is not getting into source control.
- If you only have one set of App Center keys, you can alternate build numbers to cleanly separate dev and prod stats. Odd numbers for dev and even for prod.
- If you do an Early UAT release – be sure to increment your version so you can easily distinguish between them in Analytics!
- Devise a clean way to build release notes so that you can quickly get a clean list of the improvements made since your last release. Everybody organizes things a little differently. Be able to scan through the commits since your last release, take a look at your sprint items, etc. Think about how you will do this easily.
Tip #23: Use the Golden Ratio
If you are dozing off or daydreaming… you might want to perk up and listen to this one… it is a really good way to quickly make your UI look pleasing to the eye without doing a lot of work!
- Found throughout nature and art, the Golden Ratio is magically pleasing to the human eye
- XAML allows for a easy use of the Golden Ratio, with Grid Rows and Columns
- You can use any combo of the ratio in whole numbers
- For two sections, you can also just use 1 : 1.618
Tip #24: Choose Your Plugins Wisely
Third party and open source plugins can sometimes be challenging in integrate. Make sure the benefits out weigh the cost.
When your app requires functionality that can be furnished by an open source plugin…
- Does the business require that all plugins are vetted for security purposes?
- When was the last time the plugin code was updated on GitHub?
- Browse the issues for known problems
Perhaps it can be furnished by a third party plugin…
- How often do they release updates?
- Browse their knowledge base
- Do your due diligence!
Tip #25: Synchronize Environment Updates
- Everyone on your team should be using the same version of Visual Studio and/or VS for Mac
- Discuss and plan for Visual Studio, nuget, dev device SDK and dev machine SDK updates.
- Devote one day every 4-6 weeks to update and smoke test – usually first day of a sprint.
- Read the release notes!
- Make sure you run release builds, with the linker on, to test updates on all platforms.
- Take notes so you don’t repeat the same version combination next time
- Understand this is a long process for a mac.
- Use this time wisely
- Groom the backlog, go through your notebook, read up on a POC you need to build, review your requirements and mockups, etc.
- Scan the horizon for upcoming challenges
Thanks for reading all the way to the end!
I think there’s a typo here: “get in the habit of isolating this your business rules”
Thank you!