Articles, Blog

Deliver your Enterprise Xamarin App On-Time and On-Budget | Xamarin Developer Summit

November 30, 2019


>>So welcome to Waterway 8. We’re going to talk about delivering your Xamarin app
on-time and on-budget. My name is Robin Schroeder and my
Twitter handle is RTSchroeder.>>Robin? Yes.>>[inaudible].>>Okay. I lost my voice last night because the bar
was very loud. Better?>>Yeah. Thank you..>>Cool. Sponsors. So why are you qualified
to talk to me about this slide. I like to build stuff. I’ve been coding since 1998 in
all kinds of different languages, and then in 2008, I switch to the Microsoft Stack because I married
a Microsoft developer. In 2015, I started Xamarin University and I
really fell in love with it. I’m also qualified to talk
to you about this because I have lifetime chronic nightmares
about being late, and so I spend a lot
of time thinking about ways to not make my projects late. I also have a disclosure here. I’ve no affiliation to any of the specific products that
I mentioned in this talk. I work at a small consulting company. Our office is in a maker space
which is really awesome. I play guitar and I’m also
the happy instructor of Fox Valley Girls Coding Club
so on Friday nights we eat candy and write Python code
with high school girls, and it’s a lot of fun. I would suggest that. So what am I going to talk about? Basically, I’m going to
put this in two sections. First, we’re going to review
some research on software delivery, and then I have 25 specific tips on resolving some of the problems
that come out of the research. So let’s get the depressing
stuff out of the way. Sorry in advance. One of the best examples of the worst clickbait that
you could ever see is this Geneca or Jeneca, I don’t really know
how to pronounce them, but they’re a software
consulting company out of Illinois that
basically did a survey, and these are
their exact bullet points. So if you saw this on
Twitter or on Instagram, you probably saw, 75 Percent of
Software Projects Will Fail, is the title of their article. It’s worth a read. It’s interesting and depressing at the same time. But it highlights some things
that probably a lot of you guys can mimic in your own daily lives. Unfortunately, I’m not
going to go through every Rogan awful statistic here, but basically, the highlight is that 75 percent of
respondents admit that their projects are either always or usually doomed right from the start. So it’s rough. One of the most popular
reports to look at why software projects specifically fail has to do with a group
called the Standish Group. So every year they publish
what’s called the CHAOS Report. I’m going to be using the 2015
version here because it’s free, so you can go online and read it. The 2016, ’17, ’18 and probably the ’19 version
right now are not free, so if you are a large company
and you want to pay for those reports and
then review them, you can. However, the 2015 is freely
available so you can read the details on each one of these
particular weighted statistics, but basically the Standish report takes a large survey of
a lot of leadership people in high leadership positions inside of large
companies and talks to them about why they thought
their software projects failed, and specifically what things because them to fail and what things they could have
done better or whatnot. They analyze all of those
things and put together this list of top 10
factors of success, and then they weigh them. Then they determined that
based on the weights, this amount of investment, so this percentage of
investments should go into your project planning so that you
have a better chance of success. So the top four here. If you can’t read them from the back, its executive sponsorship makes up 15 percent of what they
suggest you should invest in. Emotional maturity,
which is so ambiguous, 15 percent of your investment. User involvement, 15 percent. Optimization, which is ambiguous as well and we’ll talk about
that a lot, 15 percent. Skilled resources, which
is right up our alley, 10 percent, as
developers up our alley. Standard architecture, eight percent. Agile process, seven percent. A modest execution, which means your project has
a relatively decent size, six percent, not too big not
too small modest execution. Project management expertise
at five percent and clear business objectives
come in at four percent. So for the purposes of this talk, I’ve taken those 10 factors of success and group
them into three buckets, and then took 25 different tips for delivering Xamarin projects and
grouped them into three buckets. So I’m corresponding the problems
with the solutions basically. So we’re going to cover
25 ways to make it better. The first group of problems
and solutions have to do with these three sections of
the Standish report. Fifteen percent of
the problem that they’ve identified has to do with
executive sponsorship, 15 percent in user involvement, and four percent in
clear business objectives. So I’m calling these
communication problems basically. The first four tips have to do with communicating better
with stakeholders and users and people
on your own team. So who’s on the team?
First of all you can write software all day long as an indie developer.
It’s you and the users. You’re the developer, those are the users. They’re going to use it. Maybe you could even have one more where you’re the developer
and you’re the user, so those are already
always fun projects to do. So you’re just writing
software for yourself. In a little bit of
a more broken-out scenario, you’ve got stakeholder,
a developer, and a user. More of an enterprise
environment you’d have a stakeholder which
would be your C-level project managers and
business analysts, and then a layer of developers, some quality assurance,
and then users. So that gives you an idea of what
most projects usually look like, the stratigraphy of the team. So tip number 1, and this is probably the most important thing every
time I do this on a project, things tend to work out pretty well. That is, make weekly
progress videos and screen caps. This sounds like a lot
of work and this is stupid and I don’t want to do it, I should be writing code, I shouldn’t have to be doing this, so that’s what you’re thinking. But if you make
progress videos as you go, as you write your code, and you create area inside, so most teams talk via Slack, Teams, Discord, or something similar. If you make a separate channel
for your videos and then you upload them as
you’re writing code, you are basically creating
a visual diary of your project. You can invite your C-level people, your stakeholders,
your business analysts, whomever on your team to go log in to that little diary and take
a look at those little videos. This I’ve found is very powerful because most C-level people
are stuck in meetings all day, and you want to develop all day. So in order to have this time when you can
communicate with one another, you’re basically giving them
the ability to view, review, talk about, think about
your videos anytime they want. They can also comment in this scenario in Slack,
Teams, or Discord. They can comment in line and you
can create a conversation where a conversation needs to happen about requirements that
you may or may not have. So this is the number
one tip for a reason. I find that you get the most bang for your buck when you make
little progress videos. You’ve seen in lots
of the presentations people use Vysor or Reflector. Those are the two tools
for making up the videos. They’re not that hard to do once
you get in the habit of it. Every time you do a big commit, every time maybe you merge, you make a little video and pop
it into your Discord or Slack. Very powerful. Number 2, don’t write any code
ever without a mockup. By a mockup I don’t mean high-fidelity beautiful graphic
designer created mockup, I’m talking about a low-fidelity
not quite back of a napkin, but a quick low-fidelity mockup that’s made with a tool
that’s simple to use. I like to use Balsamiq, you could also do whiteboard drawings and then take pictures of them. Balsamiq is pretty
useful in that it makes everyone on your team
understand that this is not a finished product, that this is not a screen capture. That this is a drawing. So everybody including stakeholders understand that this is
just a conceptual idea, it’s not set in stone,
it’s very valuable. Also I think one of
the most important things here is especially as a consultant, when you get plopped
into a client who hasn’t done any work in creating
requirements and you come in and you get this very high level description
of what the client wants to do, if you start sitting
down and acting as a BA collecting requirements
usually get a lot of pushback. If you sit down and start doing
Balsamiq mockups all of a sudden, they’re drawn in to your mockups and you don’t
get that pushback that you’re wasting time because a mockup
speaks a thousand words. I think it again creates
conversations where conversations need to
happen about requirements. Number 3, make and
user must a know list. So this is my must know list, I know it’s a weird term. But when I go into a client, they give me this high -level idea
of what they want to build. Typically, we dig into those details and then I
take this list out and specifically make sure that I ask each and every
one of these things, because these are the things that affect your general architecture. So if you’re asking
three weeks into the project, “Did you guys want to convert this? Do you also want to deliver
this to Spanish users, or perhaps Portuguese,
or maybe Polish?” That’s a requirement that
I need to know on day 1, not three weeks into the project, I need to know that right up front. So to ask all of these things
that we’re going to affect your architecture is
super important to do. If I didn’t have a list going in, I may miss some of them. So by making a list and
going in on day 1 with that list it’s really helpful
and it avoids delays. Number 4, and this is
my most long-winded, but it’s also super important. That is in my last two projects, I did an early UAT, so UAT is user acceptance testing. How many of your projects have you guys ever done with
user acceptance testing. A lot of times with UAT, you do UAT oftentimes after QA, and that’s the traditional place
to put it in the pipeline, so you develop a software you, get it through QA, and
then you send it to UAT. If anything is wrong in UAT, you have to send it
right back to the devs, and devs get it to QA, and QA gets it to UAT. So I use a dependency
injection pattern here to create a sample data
only UAT version of the app, and then I give stake holders
QA device with this version of it, and basically it gets them involved. Oftentimes, the stakeholders will
bring that device to meetings, show their fellow stakeholders or their fellow C-level
people the app. It starts to get a lot of excitement about your app within
the organization, and that number 1 thing
on the Standish report, the number 1 reason
why projects fail, is stakeholder buy-in basically. So by giving your stake holders the tools that they
need to basically be your advocate throughout
this large organization that you work in, is
extremely powerful. So I’m going to go
through a couple of the technical ways to set this up, but I found this to be
a really good pattern. Basically, the way that I
describe it to them when I go in is that we’re going to set the table, we’re going to create
the UI together and make sure that it does
everything that you need to do, and then I’m going to put
a bunch of sample data in which is going to create
this tablecloth underneath. Then while you’re
figuring out and making sure with your early UAT version
of the application, making sure that all the forks, and knives, and wine bottle, and the vase are all perfectly
laid out on the table, and it’s exactly what you want, I’m going to be building
my second tablecloth which is the API layer, which has all the middle layer that’s going to feed the actual
data into the app. Then I’m going to basically
rip the tablecloth out from underneath your table setting
and everything is going to stay just put exactly
the way you like that, and then we’re going
to have an API layer. So we’re basically
dividing and conquering. I’m giving them
one version of the UI, and I’m taking the other one
and building out a different basically layer underneath. So the first step to
this is to invest in a fair amount of sample data. I usually do two or three
versions of sample data to give some examples of different scenarios that could happen with
the underlying data. This is especially even more useful with the announcement
that we had from Mattie yesterday morning about how design time data is now going to be useful inside of Xamarin Forms. So this has yet another use. So not making sample data
is a waste of time. Like just make sample data. If you use any cogeneration
in your pipeline, we use a lot of [inaudible]
because we’re a small shop. I just tend to generate
this based off of the models and then change
a couple strings and numbers in order to meet the scenarios that I want
to basically test or allow my stakeholders to play
around with in their version. I always use fictional
character names, dead presidents, cartoon characters, movie stars, and again, driving home the point that the backend is not wired
up and not complete. Never want to give them the idea that the application is done
when it’s not done, it just sets unreasonable
expectations and makes life really hard for you. So the second part of that is
to make sure that you’re using dependency injection to bifurcate the data loading and the data store. So if we took a very vanilla Xamarin Forms out
that right from the template. So in this case, I used the shell template right out of
the box in Visual Studio 2019. In the shell template, you’ve got an IDatastore interface, and then an Azure Data Store
and a Mock Data Store, so they’re doing
this pattern already. So in order to implement
the pattern that I’m talking about, I split the Azure
Data Store into a loader. So I split this interface
and created a loader, that loader is then loading up
my SQLite storage in the backend. So I’ve got an Azure Data Loader, a Mock Data Loader, and then my SQL Data Store which is where the persistent
storage layer is. In practice, if I was building an enterprise application and
I was using this pattern, I would probably break it
down a little bit more. So in the GitHub repo
for the conference, I have an example of
this that’s working. Where basically, if I’m loading the sample data store
that I’m loading these services, they’re
all singletons. So these are all getting loaded
as singleton for the data store, the data loader, and
the data uploader so that’s when the data
goes backup to Azure. Then, if I was loading
it from the API, then I would be loading
this set of services. So it’s just a bifurcation with
the dependency injection engine. I use the core one. So that’s the newer one that
if you watched a video of James doing it with implementing this pattern
from build just recently. So to visualize the comparison here. In previous situations where you have this pattern of going
from Dev to QA to UAT, I feel like the stakeholders are looking through that glass window
with the nursery. They’re wanting to see the app
and they see that little baby, little baby app sitting there, and they can’t do anything. They can’t get a good look. They can’t see, do they have
10 fingers and 10 toes. They’re not really getting
to play with your app until very late in the process. By doing an EarlyUAT pattern, you’re giving them the ability to
not only use it for themselves but you’re also giving
them the ability to share with their
fellow C-level people. So it levels expectations, it works really, really well. So again, if you want
to take a look at it, it’s inside of the Speaker Git repo. I just have a button
on that homepage. It logs the sample user out, dumps the SQLite database and
then loads it backup with either the API data or sample data
whichever button you push. So that’s tip number four. We got 21 more. So second, I’ll go fast, all right? The rest of them are more simple. So the second section from the Standish report has
three different categories. Here, it’s about 32 percent
of their weighted problem, 15 percent emotional maturity, 10 percent skilled developers, and 8 percent standard architecture. So this is our bread and butter. This is us. Who’s
a developer in here? All of us, yes. Unfortunately, 32 percent of the problem according
to Standish is us. Number five. I use this probably 10 times a day. The pulse of software
development is on Twitter. If you don’t have a Twitter account, you’re in luck because you can create one and it will be nice and clean, and you can only put
technical people in there and only follow
technical things. I have learned more on Twitter
than anywhere else in ever. I usually spend
about 5-10 minutes daily. I go through the Twitter stream. I will look through Twitter
really quick to see if anybody has problems before I do
an update of Visual Studio. I just make it a habit. I use this Microsoft
To-Do mobile app. It actually has a widget that goes on your Android desktop of
your phone. So this is my phone. It allows you to knock
things off your list. It syncs to Outlook
so that if you want to go look something up
on your laptop, you can. Then, you have this To-Do list that’s anywhere you want or
on a tablet or whatever. So it’s super useful. So what I do is that
if I’m on Twitter, I see a blog I want to go look at, I copy and paste the link to
the blog into my To-Do list. Then, the next time
I have 15 minutes, maybe I’m waiting for my kids coming out of karate class
or something, then I do a little bit
of more research on that whatever the
thing was on my list. As mobile developers, we have
to keep up and it’s hard. There’s lots of things
happening all the time. So doing something like this
and just making a habit of it, it keeps you on your toes
as a developer. The other thing too, so this is fun. A lot of times, I’ll take things on
my To-Do list and and I dream up a pet project app
for myself to build. So typically, I like to build
libraries that I’ve never used. I have given myself permission that it’s okay to fork it and
play around with new things. It’s not a waste of time. It’s okay if it never
goes to the store and it only lives on my personal device. It gives you something
to practice on, to blog about, to talk
about in interviews. It’s really valuable. Also, if you have forgotten how much fun it is to
be a developer and you have lost your love
for writing cool code, this is a great way to get it back. So here’s an app that I wrote
that and the stars rotate. Basically, so I was sitting
in a meeting a little while ago a couple of months ago
and everything was just failing. So our web connect was
failing and people weren’t showing up and the sky
was falling basically. Someone looked up and said, “Is Mercury in retrograde?” Everyone went, ”Oh
maybe, I don’t know.” So we had to Google
it and sure enough, Mercury was in retrograde. So then I was like,
”Well, if mercury in retrograde can affect this meeting, then I need to write an app
that reminds me when Mercury is an retro-grade because
this could be a disaster.” So I did and I use SkiaSharp to
rotate the stars which was fun. I did ads which I had never done. Google more of that. So it’s in Shell as well. So there’s all kinds of
things that you can do. You don’t have to have a deadline. You don’t have to report
to a stakeholder. You can just do things
on your own time. So give yourself
permission. Number seven. This one’s a little bit tough, right? So Cultivate Your Emotional Maturity. As developers, I think we find
solace in logic and code. I mean that’s why we’re
here is that it’s a very comfortable environment
to interact with a computer. That’s what we enjoy.
Unfortunately, that’s not how you write good software. Good software involves
lots of people and making sure that the software is written to meet the needs of a business process, requires that we interact
with lots of people. So this emotional maturity
according to Standish, the Standish report is
15 percent of why projects fail. So of course, I had to Google
it and figure out okay, well, what’s the difference
between emotional maturity and emotional intelligence? So these are buzzwords that
are going around right now. I would encourage you
to Google it as well. So it’s an interesting thing. Basically, it boils down to
the idea that everyone needs to stop and think what it must
feel like to be that other person. That’s pretty much
what it boils down to. If you do that and try
to practice doing that, then basically you’re practicing
your emotional maturity skills. So before you freak out because
your requirements have changed, before you freak out when the deadlines have been
moved on, you just stop, think about how everyone else in the pipeline or how everyone
else must feel. It’s complicated basically. Number 8. I watched junior developers do this a lot,
Don’tSetYourselfUpforFailure. Try, try, try to fight your natural innate excitement
for solving problems. Just because you can solve
a problem doesn’t mean you should. So this comes up pretty
often when someone comes to your development team
with a problem, and you can think of 25 ways
to solve it technically. I could write this code.
We could do this. We can put this hook over here and then put this over here
and then this can fall, but should you fix
it with technology? Are you just covering up for a bad business process that needs to be fixed
within your business. So before you solve something
with technology, stop and think. This is a huge time
sync in my opinion. This is oftentimes what
makes or breaks a project. If the developers can do something, it doesn’t always mean
that you should do it. So stop and think about that. Number 9, CelebrateYourSuccesses. I know it’s so cliche, right? This is way more important
than you may think it is. So sometimes when I lead teams
or even when I’m on teams or, however, I do a lot of
staff augmentation. So sometimes I’m in charge, sometimes I’m the shoe chef,
sometimes I’m alone. I like to make sure that my team or myself
celebrates my successes. Celebrates your success as
a team even if it’s just, how many of you have
written an app and at some point during
the development process all of a sudden you have to turn on, the decks, what’s called the decks index or whatever where you
have to click this switch inside of your Xamarin and
inside of your Android app. Like one build it was
fine and the next build, and all of a sudden you have
to turn the max decks on. It feels like your app is growing up. You’re like, ”Oh my kid has graduated from second grade
to third grade now.” Stop, celebrate that. That’s a little
celebration like, hey, we got to the point
where we have over 6,400 methods inside of our or, however, many it is 64,000. So it’s a good thing
to do to stop and say, ”Hey, we’re getting
somewhere. Let’s keep going.” It doesn’t have to be the end
or beginning of a sprint, but it’s super-important to
celebrate your successes. The third section according to the standard support has
to do with optimization. A lot of this has to do with avoiding delays in the development cycle. So they cite optimization as
15 percent of the problem. Agile process, seven percent or these are the estimate
of how much you should invest in each one of these things
to deliver to increase the risk or to decrease the risk
of a project failing. Modest execution which we’ll
talk about in a minute, and then project
management expertise, so that may or may not fall into
something that we can modify. So about 33 percent of the problem
has to do with this category. Sorry, I yelled right there. Donovan Brown, couldn’t have
said it better this morning. He was it a lot more
aggressive about it, not aggressive, but
passionate about it. But if you set up your CI pipeline, your analytics, and crash
reporting on day one, you are going to collect a lot
of great data and you will be able to move forward
in a much better way. So a lot of times I see teams
wait to set this stuff up. If you’ve set up especially
your CI pipeline on day one, then basically you’re
setting up your CI pipeline to build an empty solution
basically with just your bare-bones
template and you’ll get it working much faster
if you do it on day one. Then, you’ll figure out
which build broke it. I added this library, now my build is broken
and my CI pipeline. Now I know at least somewhere
between point A and B. This chunk, these five commits
somewhere in that area it broke. So it’s much easier to figure
out what happened to break your build when you
set it up on day one. Also, these little badges that come in App Center are super
valuable because you can see then how each one of your builds is passing or failing really quickly
without having to click around. It also gives you an indication of if any of you
the developers on your team are spinning and then
you can try to go and get them unstuck
especially if they’re remote. So this also allows you to then
create meaningful analytics. So this is pretty important as well. We can collect analytics all
day long but if they’re not meaningful then it doesn’t
matter that we collected them. It was just a waste of time. So how many of you guys
use App Center? App Center is great. If you want, I totally
offsets subject now but I have these on
Mobile Centers stickers. So remember when you used
to be called Mobile Center like collector’s edition
Mobile Centers stickers. I have a couple of we
went from they’re cool. Anyway, I wouldn’t really
remembers anymore but the thread at least to me. So here’s an example
of a track event, and this one’s called pass
the string successful login, and then I make a dictionary here. I passed user and
then the user e-mail. When I’m looking at
this in App Center, then I’ve got my
Successful Login here. It very quickly is able
to give me a graph of how many times I had
a successful login event. Then, I’m able to see down here okay, these are all the users that have logged in and the number of times. If I had taken this user e-mail and put it inside of the string here Successful Login and then concatenated the e-mail
address at the end, I would have garbage here and
I would have nothing to see, it would be a waste of energy. So making sure that
you’re able to integrate meaningful analytics
is super important. Again, making sure that those analytics are going
in as you’re writing code is also super important because you’re able to track from
day one what’s going on. Number 11, Monitor Crashes. Inside of App Center there is
these two handy-dandy little things. Number 1 is this little icon where
you can write a little note. Hey oops, sorry, this happened
because I was missing a column on SQLite table.
Then my initials. Or and also next to this handy-dandy
little button is an under handy-dandy little dropdown menu
that’s allowing you to mark each one of these crashes
as open closed or ignored. I use this all the time because
sometimes crashes can repeat, sometimes you’ll be able to cause the same crash with
a different scenario, and you can very quickly have a little diary of the times
that your app crashed. So this is a super, super important feature
that’s already there. It’s free, and you should use it. It saves a lot of time. So crashes often also involve multiple developers
and that wastes a lot of time for multiple developers. So using this type of
stuff is important. I use whenever I’m on a team, I always picky that everybody uses
an extension called CodeMaid. CodeMaid, it auto cleans and auto reorganizes each one
of your code files on save. This reduces merge conflicts. So merge conflicts are one of
the biggest sinks of time ever. S to avoid them is fabulous. So basically code made out of the box alphabetizes
the members of the same group. So all of your methods
get alphabetized. There are some settings but
typically I just use the out of the box settings and
then everybody that comes on the team has
to install CodeMaid. It’s really a very quick check when you have a developer
that doesn’t have CodeMaid turned on then everybody
knows it because you end up having merge conflicts or
at least sticky merges. Merges where wait we lost that somewhere. ”Oh
how did we lose it?” Then we have to go back in history. It’s a waste of time. So
using CodeMaid helps a lot. Alleviate some of those problems. Number 13, Identifying
the Hard Parts and TimeBoxing your proof of
concepts. How am I doing? Oh my, I’m on 13. So everybody knows what
a proof of concept is. It’s when you just write
a little bit of code. When you timebox your
proof of concepts, you’re basically
using a set amount of time to go and write
a proof of concept. That’s super important and having the discipline to do
this so that you’re not spinning by yourself is
crucially important lots of value. Number 14, Build an MVP, a minimum viable product
with ”Good Bones”. Never count on being able to
go back and rework your MVP. If it’s your MVP, that’s
not a proof of concept. A proof-of-concept is
something you’re going to probably learn from and throw away. An MVP is a very early
larval version of your app. Number 15, try, try, try to push the business rules
back in your architecture. Try to get your business rules out of your view models. I know it’s hard. But as we move into an environment where we have things like the Uno
platform and XAML, we’re going to be able to share business rules with
Xamarin or Xamarin apps or APIs and now those web component because we’re going to
be writing them in C#. If you push your business rules
back in your architectures, you’re going to be able to reuse them in all kinds of
different places. Get in the habit of doing this now and it’s going to save
you a lot of time. Number 16, BattleContextSwitching. Do you know a context
switching is where we’re changing projects every five minutes? So I’ve divided this into two. Try to reduce how often
you context switch. It’s hard to do. Second,
try to figure out the most graceful way
to recover when you are disrupted because you’re
going to get disrupted. The way that I do it the
most and I’m very auditory, but I tend to listen to
the same type of music or the actually the same album or sometimes even the
same song on repeat. Then, when I come back to
that piece of code or that project, I put that song back on. All of a sudden my brain
remembers what I was doing. It is the stupid and weirdest
thing ever you guys can all laugh at me
privately, but it works. It may work for you. So I’m
just throwing it out there. [inaudible] Oh my gosh, I feel so much better. [inaudible]. I have specific songs
for different projects. Expect that you’re going to have Apple Developer Membership Delays. You’re going to have them
in two major places; when the initial legal
agreements are signed, and then when you update
a license agreement, it’s going to stop your
development team in their tracks. So just know this is happening. Just it’s going to happen. iTunes submission. How many of you are frustrated
with your iTunes submission? Oh, I’m not alone. I think that they’re allergic to approving an app on the first try. Has anybody gotten one through
on the first try, anyone? Have you really? Was it a long time ago? Yeah.>>Monday.>>Was it Monday? You got one
through on the first try on Monday.>>On the same day later on.>>No way.>>Yeah.>>Wow.>>I know, also.>>I’m impressed. We should chat. Never happened to me
ever, ever, ever. In fact, lately I did
two MVPs in 2019. Both of them were basically sent back to me because they didn’t have
enough functionality. I was like, it’s an MVP. That’s why we call it
MVP, minimum viable. Anyway. Just know there’s going to be delays related to this
and schedule for them. Understand them, know that it’s going to take a while to get through. Who uses the Visual Studio
Built In Task List? Please, everyone raise your hand. Yes, please. You can
actually configure. So in your code, if you do forward slash, forward slash TODO and then a colon, all of those items end
up in this task list. All you do is go, let’s see, inside of the Options menu you
choose Task Lists or Ctrl WT, and you can pull up this list. This is fabulous for leaving
yourself a little message, and then before you go to
production or to QA or whatever, reviewing this list and
making sure that there’s no things that you haven’t touched. You can also make your own. So everyone on your team
can have their own token. Super valuable and built-in.>>It’s also available on Mac.>>Yes. It’s also on the Mac. First 10, last 10. So I have this rule. I have a notebook
next to my keyboard. When something pops in my head, I don’t want to distract
myself from coding, so I jot it down in my notebook
and I spend the first 10 and the last 10 minutes of
the day reviewing that notebook. At the beginning and
the end of each sprint, I clear my notebook to make sure that everything on
the notebook it has been cleared, it has been resolved or addressed. I use Rocketbook. If you haven’t used Rocketbook, you should Google it,
they’re pretty rad, they are erasable, and
you can scan them. There’s an app that goes right
into wherever you can direct it, to Dropbox, or IDrive, or I whatever, or e-mail, or you can send it via your phone. So it’s pretty rad. Number 21, avoid late summer public releases. We probably all know about this. Android and iOS are going
to throw us a curveball, whether it’s a new bezel, or it’s a change in
location device permissions, or its authentication
with facial recognition. You’re going to get
a curveball in late summer. So just understand it
and know it’s coming, and give yourself
a little bit of time, or just avoid late summer
public releases altogether. Twenty-two, Keep
your Build Numbers in Sync. So this doesn’t happen super often, but I have seen teams do this. Particularly, they don’t have their iOS UWP or Android
versions in sync, which is really hard to track. Then, sometimes what people will
do is use Azure DevOps or TFS. They’ll have a CI/CD script
to increment the build, and then the version number never
gets back into source control, and they don’t know
how to make a hot fix. Make sure that you are completely ready to make
a hot fix at anytime. I think that’s probably the worst. It’s the one time that
you need to be organized and ready to go, and it’s oftentimes, the time that you’re not ready to go, is when you’ve botched
up your build numbers. Twenty-three, if you’re
sleeping right now, please knock your neighbor gently
because this is really cool. I might even make a blog post. Use the Golden Ratio. So the Golden Ratio is a ratio that artists used to make
things pleasing to the eye. I’m not a graphic designer
and none of us are. So by using something that’s
already built into XAML, which is this ratio-type way to set the width and
the length of the grid. You’re able to mimic
this pattern like artists do, and we can actually get
it down to the tens, hundreds here by saying, “Hey, the height of this is one, and the height of this is 1.618.” Otherwise, you can split up
your grids by five-star, eight-star, or three-two-eight,
or something like that. This pattern, the shape is
extremely pleasing to the eye. If you don’t believe, me try it. I’ve done it a number of times, people just look at
your app and they go, “Wow, that looks great,” and
they don’t know why.>>Why don’t you actually
explain what it was [inaudible] discuss it later.>>Cool. The times I’ve used this, it’s worked out really
well, and it’s just magic. You are tricking humans’ eyeballs
to like your stuff. So good stuff. Number 24, Choose
Your Plugins Wisely. I probably don’t have
to tell you this. Review the plugins that
you’re going to use. How often do they release an update, browse their knowledge base. Make sure that this is worth
your investment in time. I love people putting
Open Source things up there. But if I’m working for
a big corporate client, I don’t want to have to be crazy
and have to find solutions to problems in [inaudible]
packages that I can’t get in and update myself because
they belong to someone else. Twenty-five, Synchronize
your Environment Updates. Understand that everyone in
your team should be using the exact same version of
Visual Studio and or VS for Mac. Discuss it and plan your updates
to different NuGet packages, and then devote one day every four to six weeks to updates
and smoke testing. Usually, the first day of a sprint, when you make release builds, do it with the linker on to test all the updates
on all your platforms. Do that on a regular basis so you don’t get to
the end and you’re like, “Oh crap, the linker doesn’t work. Oh, it’s this plugin that
we invested a bunch of time and energy in using
that’s not linker-safe.” Take notes so you don’t repeat
the same version combination. This used to be a bigger
problem than it is now, it’s a little bit better now. Just understand this is
a long process for Mac and iOS. It’s going to take a few hours
to update all of your devices. It’s going to take a few hours
to update everything. That is it. We got through it. I hope I’m not too far over. Anyone? Did I talk
too fast? Go ahead.>>Thanks. Have you
ever had any issues with clients in the rules of
licensing in NuGet packages?>>Licensing? Oh, like
third party in NuGet packages?>>Like, [inaudible]>>Sometimes. Banks
sometimes have that problem where they don’t want to
have third-party things, and they just write it from scratch. I used to do a lot of
Windows 8.1 development. I know, I’m sorry if
that hurt your ears. But in Windows 8.1, I had a client that didn’t
want any third party at all, and so we wrote everything
in-house and it actually worked out really well
because Windows 8.1, they’re still using it,
and they’re able to. There’s no support for some of those libraries that
have now gone on, and there’s perfectly happily.>>Let’s talk this morning. There was something
valuable that just happened with
their update line there. I figure that it has to do with the licenses going
into your file [inaudible]>>Yeah. I have a note to myself in my application to go
look at that because he had a scanner that would
go through and look at all the licenses to all of
your NuGet packages and then determine if you were in violation because you
had implemented or used something that had a license
that would not allow you to do that for financial gain or whatever. So some legal ramifications. So yeah, that was cool. I have got to hook something like
that up and see how it works.>>Can you repeat number 21.>>Number 21. Oh wow. I don’t know what number 21 was. Avoid late summer public releases. Did you really take
a picture of all of them?>>I want to take notes on this. I want to do this whole [inaudible]>>I did. Because I
mean, this is common. There’s all kinds of people
that talk about this. It’s because they do all
of their announcements, say the Betas will come out in July, and then come August it’s
like a realization and you can’t fall behind in mobile. You just can’t because
of this type of thing. You got to go with the flow.>>Do you have any pictures of
Golden Ratio, like in pictures?>>I could Google it real
fast if you want to know. If you’ve ever seen the Natalie
shell picture, which is common. No. There’s some action
needed, apparently. Some required action. I don’t know where
my access codes are. Anyway, the very classic picture is this Natalie shell that
has this scrawly shape. So honestly, it’s magic. I don’t know really how it happens. But this shape right here
has a Natalie shell. You can see its magic, so you should use it. The cool part about it is that, XAML is set up to do it
every which way from Sunday. So it’s a cool little trick. Anybody else? Oh, that’s my alarm.

You Might Also Like

1 Comment

  • Reply Erhan Alankus November 28, 2019 at 9:17 pm

    Great talk. Is there a link to the slides?
    edit: https://www.msctek.com/deliver-your-xamarin-app-on-time-and-on-budget-part-1/

  • Leave a Reply