Our Golf App

I wanted to share my feeling at watching the scoreboards on Sunday February 18^th, 2018.  It is awesome to know that I’ve built a system that people can use and I don’t have to be around to see.  It’s hard when things start.  Your goal when you start is not to have everything perfect.  Your goal is to have something that people can use initially.  It’s not perfect.  It is a start.  Initially, it is called a Minimum Viable Product.  Minimum is the key.  You start with the minimum set of features that people can use.  Over time, you add features.  You improve the product.  That is called iteration.  And that is what I have done.  I have taken a product that I had to go to the golf course to run to now, the golf assistant procs can run the application with no interaction from me.  For the club games, we have things to the point where a golf pro just needs to:

• Select which club game a group is playing.  The game type, game settings, and money are all preset.  The only thing the pros need to do is select the players, hit the start button, and the players are off and running.
• Players and teams can setup prebuilt side games quickly and easily while on the course.
• The players handicaps are stored and updated as necessary.
• The scoring and money is calculating in real time.

The club games are just about as easy as can be to setup.  The only thing that could make it easier is the brain tie in where you just think it, and the game, teams, and players are setup for you.  What does this do?  It eliminates

• The 20-90 minutes afterwards in figuring out the score and the money.  We talk about wanting to have time back in our lives.  If my game was so complicated that it took 90 minutes to get my money, I’d want out quicker as well.
• The errors.  If you play a handicapped game, 60-70% of your scores are wrong.  Don’t you want that better?

Hack Attack - https://golfeventscores.azurewebsites.net/PublicScores/TeamGameScoreBoard?TournamentId=31483&displaymoney=true

Low Handicap - https://golfeventscores.azurewebsites.net/PublicScores/TeamGameScoreBoard?TournamentId=31485&displaymoney=true

And then there is the charity games.  This is truly a package that any club/course could use. We have this down to a package that you import our spreadsheet that you have filled out, print out the qr code page, and the users download our app.  The user starts our app, points at the qr code, and the teams are keeping score.

• The tournament director can fill out a spreadsheet of teams and players.  This can be imported into an event.  Boom, the teams and players are created.
• The players will need to download an app for either the iPhone or android app stores.  With this app, the players can scan a supplied qr code.  The supplied qr code allows a person to start scoring for their team.
• The only thing the golf pro staff has to do is put the print outs of the qr codes on the golf carts or handed to the players as they check-in.  Scan the qr code, and scoring can start.  That’s it.  
• This saves somewhere between 60 & 90 minutes after the event for players in seeing the scoreboard and results.  This cuts down on the time for the golf pro staff as well as all of the players.  Time is money.  
• The results are calculated in real time and follow the USGA guidelines for tie breaking.
• Pictures and video can be uploaded in real time and are immediately available in the application.

All of these features create a truly memorable experience.  I am very proud of what has been built.  I am working to get our product out to as many charities as possible.  Please contact me so that we can help your charity generate more money from its charity golf events.

Here is a link to the Boys & Girls Club of the Smoky Mountains.  Please check out the pictures and videos that are on the score board.

Boys & Girls Club Smoky Mountains on the River Course at Sevierville Golf Club - https://golfeventscores.azurewebsites.net/PublicScores/SingleScoreMultiplePlayersSummary?TournamentId=31427

Overview of Tournament Director : https://www.youtube.com/watch?v=LhMFaC-is04

Overview of the Scramble System: https://www.youtube.com/watch?v=uUnzJZVJSb4

Through a Mirror Darkly - The Not So Positive Look At Startups From The Inside - Part 2

This is part 2 in my series on the things to be nervous about startup risk for the developer.

People Doing Their Work 

Unfortunately, people tend to over promise and under deliver. In a corporate environment, there is at least some amount of requirement that people do their work. In a startup, some people just won't do their work. I've seen this across several startups. The most jarring example was a startup that needed to raise money. For whatever reason, the founder would say that they were going to talk to angels and VCs. In reality, they never made the first attempt. People are often intimidated when they are out of their comfort zone. The last thing that they want to do is something that they are uncomfortable with. You have to watch this and hold people accountable. If I am a developer that is expected to give up their life for a startup, I am expecting other people to do the same thing. To push this along, one has to be really careful. Just asking "why haven't you done this yet?" is probably a bad question. Asking what you can do to help move something along is probably a better question.

Helpers

Sometimes, you have helpers. As a developer, you have people that want to explain to you how to implement something. They may or may not actually understand what is happening. Unfortunately, they tend to think that they are subject matter experts. I refer to these people as "drive-by subject matter experts." Don't get mad at these people. They are trying to help, however, their help is going to cause more harm than good. The danger of these people is that they will get locked into one thing. They might claim that the one thing they are talking about is an absolute requirement when the feature they are talking about is really just a "nice to have." How do you handle these people? These people are really just looking for something to do. I've always worked on giving them something to do that is helpful to the startup, but not associated with the development. Get them to write blog posts, test an application, or do something else.  Just come up with something to get them out of your hair.

Money

Financial risk is a major problem. Negotiation to handle this upfront is key. Unfortunately, this rarely happens. People are working their hardest. Money gets forgotten about until it is too late. Unfortunately, the most money today gets spent on development. Unfortunately, development is where the most stress in a startup is. It is unrealistic to put the developers at financial risk in this area. Developers need to protect themselves in this area. I've had this issue come up three times personally. The best example of this is a question on Quora asking for advice on how much personal financial risk is acceptable for a developer at a startup. The question implied that the developer was being asked to indemnify the startup investors against financial loss. Startups are risky, and that is the nature of the beast. Each situation is different. Do your best to protect yourself. There is often the expectation that developers will work for free forever. Nothing could be further from the truth. I don't mind helping people, but my help comes with several conditions:

• I'm not doing this for free forever. I don't mind helping you get into first gear with a prototype, but you need to be out there working on customers and funding. I've had this happen.  Nothing kills a relationship quicker than "We're going to fail without you, so this is your fault."
• I'm an investor. My investment is my time and my code. Respect my time and my code. Don't bark dates at me.
• Code isn't to just be handed around. Code has business rules within it. I'm not sure why a new "low cost" developer is going to immediately understand business rules, yet I see this a lot, especially for those that do not have software development experience. Writing code for a startup is a two way street and a long term relationship. You want people that you can trust, on both sides. Can I trust you if you want to just ship code around with no thought of the how things work?

Existing Code

Existing code that a startup wants you to take over, wow, is that dangerous. The expectation of the startup is that with a few well-placed corrections, their code will go from a complete mess to a smooth running application that scales. This never happens, and here is why:

• Code was written by someone that is no longer in the startup. There is a reason why they are no longer in the startup. The most common reason is that a new feature was needed and the original developer could not deliver. The call for a new feature became deafening. The original developer got tired of this, or the rest in the group go tired of waiting. The end result is that the person is no longer in the startup. 
• Code that was written by someone else has business rules embedded in that you are not privy to as well as idiosyncrasies of the original developer within it. You need help in deciphering this, however, that person is not around. Even if you can get ahold of them, that person is not going to be forth coming regarding any ideas or solutions.
• Most likely, the previous developer was not paid for their work. They just want out. They are working on other things now. When you are in this situation, you, and the startup, are better off just starting over. This one is a tough pill for everyone to swallow. To the startup, this looks like they are throwing away their existing investment. They are. Software that doesn't work results in a sunk cost. People have a lot of trouble coming to this conclusion. The non-developers in the group will view this as additional delays and will be against the idea. The attachment to existing code seems to border on the "Stockholm Syndrome." Almost always, there will be too much trouble trying to breathe life back into the code.  Don't waste your time

Part 3 of this series will be out shortly

Startup Posts

I wanted to tie together a few of my startup articles designed for developers and to put them into one place where I can access them.  Here are my articles from Visual Studio Magazine over the past few years.

• What It Takes To Get Your App To Market
• Refining Your Developer App for the Right Market
• Can You Go It Alone?
• If You Build It, Will Users Come?
• Your App Needs an MVP
• Developer Startups Can Be Pure Comedy
• Through a Mirror Darkly - Part 1
• Through a Mirror Darkly - Part 2
• Through a Mirror Darkly - Part 3
• The Business of Risk

I'd also like to add that these are merely my views.  These aren't rants.  I'm going to eventually get around to what I think causes startup failures.

Through A Mirror, Darkly - The Not So Positive Look At Startups From The Inside - Part 1

Note: This is my experience consulting with a number of startups over the last 4-5 years. I’ve seen certain trends. I’ve talked with other developers and they have seen similar.  This is a combination of the problems I have seen. It is not a complaining about these people, just a reality check that you need to have.

In a recent article, I discussed the general concept of risk and the startup process.  This is great information if you are pushing your startup idea forward.  We’re not all pushing OUR idea forward.  Sometimes, we’ve been asked to join someone else’s startup, attend a startup weekend, or help someone else’s startup that has had some problems.  The end result is that we are pushing someone else’s idea forward.  Unfortunately, these people may have different expectations to you, and from development reality.  In this article, I’ll walk through a few issues that I have seen.  This is taken from my experiences in the southeastern US in several locations.

Expectations

Managing the expectations of other people in a startup is incredibly hard.  Most people have no idea what software development is.  They don’t understand the unit of work, how to be successful, or how they can contribute to be helpful.  To the others, you might as well be working in the back room, standing over a cauldron, and saying some magic spells.

You must be able to manage the expectations of everyone in the startup.  You will need to be comfortable in this scenario.  Managing expectations is hard, some might say it is impossible.  It is also incredibly hard mentally as well as financially.  It is hard mentally when you are getting questions on a feature every day.  It is hard to say it is weeks, or months away.  It becomes especially hard when someone else says that they can produce a feature in some small amount of time.  Many people will be willing to try this in thinking that in the short term, it will all work out.  Many times it does not work out at all, but that is a much later argument.  This becomes a financial issue when the question of you vs. someone else comes up and how any money flows.

The bottom line is that you need to manage the expectations of the others on the team.  What happens when the other people won’t accept what you are telling them?  That is when you have some amount of conflict.  The solution to the issue depends on what the conflict is.  Conflict over scheduling can be solved by having a priority list of features.  If someone wants something to be done sooner, then the order of the priorities can be changed. That is a simple solution that tends to work out.  People understand priorities and can stick with this.

Another issue is that people will not believe you.  My favorite one of these was “You should have built this with a web app so that we could not have to deal with paying 30% to the app store.”  Another great line that I have heard is something along the line of “My friend’s cousin’s son can do that in a basement in their sleep.”  There is very little that can be done in this scenario.  No matter the facts, sometimes people will not believe you.  Keep an open mind on these issues.  They could be correct, however, the possibilities in these scenarios is pretty small.

Another idea that comes up is that more developers will solve a problem quicker.  Much like threading, or multiple cpus in a computer, reality is different.  Management between multiple threads or multiple CPUs requires time, effort, and cycles.  The same is true with multiple developers.  The secret I have found is that everyone needs to be in the same location and they need to communicate when there is an issue.  This will solve the issue of communication that doesn’t work in a phone call, email, or IM.

The Burned Entrepreneur

Developers are typically well meaning people.  Not everything works out.  Entrepreneurs tend to blame the developers, no matter what actually happened. Developers blame the entrepreneur.  The truth is typically somewhere in the middle. Unfortunately, the entrepreneur will try to recoup their investment either consciously or subconsciously.  Two examples that I want to share:

• A startup had spent somewhere between $300 & $500k developing several prototypes and the developers would not do any more without additional money. I felt sorry for the developers because they had clearly been given unrealistic goals and had bad leadership. The startup wanted me to come in, fix all the problems, and basically work for free and cut of ownership; basically, an unrealistic request driven by their not having anything to show from the initial investment.

• I spoke with an entrepreneur that wanted me to come onboard of his startup. He had gone through a round of development with very little to show.  He had spent about $150k according to him, but with some missing features.  He wanted to contractually require an absurd number of hours per week once and was only promising some stock, and no money. 

In neither of these situations were these necessarily bad people.  They had not been successful initially.  In their mind, they were trying something different.  Unfortunately, they were transferring all of the risk from themselves to the developer.  Be careful.



Look for Part 2 of the article shortly.

Building For The iPhone X - The Notch and Safe Areas

Check out my article on taking advantage of the iPhone X https://visualstudiomagazine.com/articles/2018/01/09/building-for-iphone-x.aspx

-

When Apple released the much-anticipated iPhone X on Nov. 3, it generated a surprising amount of interest in a phone that starts at nearly $1,000. Initial delivery dates were four to six weeks out for those who didn't get their initial preorders in. Amid all of the excitement about the new phone, Apple released iOS 11.1 and Xcode 9.1 (followed by the release of 9.2 stable last month). You can now take "full advantage" of the iPhone X. This article will look at what you need to do to leverage this advantage and ensure your apps look right on the iPhone X.

Xamarin and iOS11

Url: https://visualstudiomagazine.com/articles/2017/10/01/introduction-to-ios-11.aspx

It’s that time of year. Each year the fall season brings a winding down of summer fun, changing of the leaves, football and a new version of Apple’s iOS. The fall of 2017 is no different. My college football team lost the first weekend -- on national TV -- and Apple has delivered iOS 11.

iOS 11 is the latest version of Apple’s mobile app OS. It has a lot of new APIs and UI changes and comes loaded on the most recent iPhones (iPhone 8 models and the new iPhone X). iOS 11 comes with a new set of APIs that developers will care about. 

Xamarin.Forms Updates - September/October 2017

I've got a new article out on Xamarin.Forms.  It is a look at some of the features that just came out as well as some features coming out in the next major release (3.0).  The 3.0 release is stated as being out in the 4th quarter, 2017, but we will see.  I never trust shipment dates.  :-)

Note: Xamarin called the next update version 2.3.5 at the time the article was written.  The version was changed to 2.4 right before the article was published and we didn't know until it was too late.

Url: https://visualstudiomagazine.com/articles/2017/09/01/xamarinforms-updates.aspx

I have an interesting relationship with Xamarin.Forms (XF). My view of cross-platform interfaces was born back in 1993 during a hallway conversation regarding cross-platform (Windows and Mac at the time) and how an interface that looked like Windows on the Mac meant the Mac users were going to come for you with pitchforks.

I had several conversations from 2011 to 2013 with various people from Xamarin about the need for a cross-platform visual UI for mobile devices. Basically, I was hearing from customers that there was a need for a cross-platform UI API. There needed to be some type of API that developers could call for buttons, textboxes and lists that spanned iOS and Android platforms. My favorite response was: "When hell freezes over." I laughed about this because I hate cross-platform APIs that don’t look like the underlying platform. I’ve seen this several times with cross-platform UIs.

Then I was in Las Vegas in 2013 and my friend told me that "Hell has indeed frozen over." I laughed because I knew exactly what he was talking about. A few weeks later I was in San Francisco and had about three hours of discussion with Jason Smith -- the mastermind behind XF who comes from the gaming industry where performance is key -- regarding XF, how it would work, some of the underlying pieces and a bunch of things that were well over my head.

Fast forward almost four years, and I’ve seen some highs and lows with XF. It works well for things that are fairly simple. For apps that are complex, I’ve been less sold on the idea. Having to load a lot of external components to get the native device functionality into a project isn’t a formula for success, I found. I’ve been bitten by components no longer supported, components not working as advertised and my general distrust for components not part of a main product package. Add with the experience of XF running fine on iOS and horribly slow on anything but the most recent Android devices, I’d become quite concerned about the feasibility of XF. I’ve been concerned about the amount of dependence on XF as the singular cross-platform development solution with Xamarin. Thankfully, over the past year I’ve doubled down on my testing of XF. I’ve written two applications for my startup and used XF. Each application has been thoroughly tested on my 2-year-old Android phone. These apps seem to run well, but they’re admittedly simple and might not be a good example measurement. After all, both deal more with data, pictures and Web services than they do with a lot of UI interaction.

Enjoy, and thanks for reading.