In Depth App-to-Market: The Business of Risk

Description: Your life isn't like the movies. In the real world even the best ideas can fail spectacularly if the risks aren't managed. It's time we talk about risk and what it can mean for success or failure of your app.  

Remember that scene in Risky Business where Tom Cruise stays upright as he slides across the floor in socks and tighty-whities, lip-syncing Bob Seger? In the alternative universe, sometimes he slips and falls. Some startups will slide through and succeed, and others might just land with a thud. That's real life.

Whether you're a developer taking your first step or a seasoned veteran of dozens of startups: Taking your idea from app to market is risky business. That's the subject of this ongoing series: How technologists take on risk in their startups and how risk affects your business.

What is Risk?

Risk is a term that gets thrown around a lot, but what does this mean?  The general definition of risk is the potential to lose something that has value, or to have a decrease in the value of something. 

Discussions of risk tend to be very subjective.  What is risk to one person, might not be considered risk to someone else.  I have also seen risk defined as anything associated with an unknown – it was a popular way of defining it when I worked at The Coca-Cola Company in Atlanta.  In fact, TCCC would pay extra just to remove risk.  I saw many things that were about the elimination of any risk no matter how small.“It’s not real money, it’s Coca-Cola money, so we should do this," is how my boss there would justify it. "It eliminates risk.” 

That's the thing: Completely eliminating risk can be very expensive. If you are at a large company and have money that is not yours, that may be okay.  But most startups don't have the resources of a large company like TCCC, and we definitely don’t have the money to completely eliminate risk. There is typically a tradeoff with risk of money and/or value. Taking the appropriate risks can result in the creation of value or at least some type of savings.  Startups can easily create value, as well as cost saving, by knowing when to take risks.  Let’s look at several types of risk that are commonly found in startups/business.

Angels and Venture Capitalists

The world of angels and VCs tends to be filled with risk.  Look at most of the financial news and you'll see lots of angels and VCs  making a lot of investments, but very few get reported on as being successes.  Why would anyone want to get into that world?  It just makes no sense.  However, by managing that risk, success can be found.  Let’s look at these investments by the numbers:

Let’s start with the assumption that the angel/VC is not a fool and does not just throw their money away in bad investments.  Assume that the angel/VC can get a 10 percent success rate.  Ten percent of the investments rest in a successful company, and 10 percent of their investments will lead to a successful exit.  That means that a single investment is unsuccessful 90 percent of the time.

To keep the numbers simple, let’s assume that the angel/VC makes 10 investments.  This means that .90¹⁰ is the probability of complete failure.  This equates to roughly 34.8 percent, and so this means that there is a roughly 35 percent chance that nothing will be successful.  This is a worst-case scenario.  And guess what? It is a bit worse than it appears.  For a technology startup, the results are typically either win big or get nothing.  Any software that is written is not typically salvageable.  This is different from something like a real estate investment where if the investment does not work out, there is typically some land or a building that can be worked with. 

From a mathematical standpoint, the surest way to success is to continually invest in companies.  Each investment will knock down the probability of total failure.  This goes along with the view in the investing world that the surest way to success is deal flow.  The more investments that an angel/VC makes, the higher the probability there will be some number of paybacks.  Increasing the number of their investments reduces their risk and tends to increase their income.  From the standpoint of math, this makes sense.  When it is your money, it is a different scenario, and you can be a bit gun shy to continually toss money into what looks to be a losing set of investments.

Let’s assume that an angel/VC is making 10 investments of $50,000 each.  This means that there has been a total investment of $500,000.

Investments tend to have a return distribution where one out of 10 is a great return.  A great return for an early-stage investment would be something like a 40x return.  A couple of them are good investments that return three times the investment, and the rest are dogs that return nothing, like this:

$50k x 40 = $2 million return

$50k x 3 x 2 = $300k return

A total return of $2.3 million

The numbers can change depending on the situation.  For example, if there is only a one-in-20 chance of making a great return, then the projected return would be $1.3 million.

In looking at the numbers, the only thing that really matters are the big winners.  The small wins just don’t matter that much.  This is the reason why angels/VCs chase what are called "unicorns."  The big returns (unicorns) make an investment fund work.  This is one of the counterintuitive things about investments.  Good wins, where you return 2x, don’t tend to matter.  For the VC system to work, you have to have big wins.

Over the course of a VC fund, it is looking to make multiple investments in a company  If a series A was made by a fund on day 1, then several years later, it is looking to make a follow on investment.  If a VC doesn’t make a follow on investment, that tends to look bad to other potential investors.  The VC will need to keep some money in the fund for those follow on investments.

So, let’s analyze this series of investments.  These returns sound great until the time value of money is factored into this.  With the time value of money, a dollar today tends to be worth less than a dollar tomorrow.  This is due to inflation and the fact that there are other investments out there. 

Angels and early stage VCs tend to have a long time from investment to a return.  As of late 2015, the time frame for a payback can be as much as 8-to-10 years.  Assuming that there is an average 10-year timeframe to get money back, it depends on the options if this is a good investment or not.  Assuming a 7 percent return in a relatively safe investment vehicle, an investment of $500,000 would become $983,000 over the same timeframe.  The investment roughly doubles, the money is much more available, and the investment tends to be safer. 

If there is a big winner out there, an angel/VC can be a big winner.  If there are no big home runs in the investment portfolio, the fund will be a loser.  Remember at the beginning, there is a 35 percent chance of having no return in a series of ten investments. 

So, which makes more sense for an investor?  High tech investors will understand these probabilities.  However, I have watched investors -- who did not understand technology investments -- put $25 million into technology investments and come out with nothing. I wish I had gotten in on receiving that money.  The investors wish that they had made other investments now in the aftermath.  I’ve also watched others make this work, because they understood the risk and how to manage it. 

A word of warning: Just because someone dresses nice and is in a pseudo-government position, it does not mean that they understand technology investments.  But let's move on…

How can you work better knowing this?  The key to you and your startup is to show the angel/VC community that you can be the next big winner for their investment.

Software Choices – Technology Risk

While technology choices don’t matter a lot to the success of a startup, there are some choices that do matter.  One of the goals in a startup should be to eliminate as much technology risk as possible.  What is technology risk?  Tech risk is often thought to be any type of risk associated with the technology.  This could be one of several issues including:

·       The technology does not get supported long term.  An example of this is Silverlight in the area of cross platform software web development.  Silverlight looked really great in 2007 in all the demoes that were done showing off cross platform development.  Unfortunately, the technology landscape changed with mobile (iPhone and Android).  With no ability to get on mobile devices, the technology languished and finally died by 2012.

·       Developers that want to look cool by doing something different.  It may seem that it is “micro management” to define the libraries that are allowed to be used.  Unfortunately, developers tend to think of solving problems now, and don’t necessarily look at the tools that will be there long term.  For example, I was working for a startup once.  We needed to do some HTML dom manipulation.  Even in 2007/8, it was clear that jQuery was the solution for this.  No, somebody else wanted to use a library called Scriptaculous.  Why?  Because jQuery was too popular.  A little bit of thought and it was obvious that Scriptaculous was a loser and that jQuery was going to win.

·       Just adding libraries -- with, at best, questionable benefits -- to a project because it is cool or innovative is not acceptable. One can easily find the various code repositories rife with cutting edge or nifty open source libraries that have been abandoned or not updated in the last 5 to 8 years.  So, just because a library saves developers a couple of lines of code doesn’t mean that that library should be added to your project. When you add a library, choose the most popular one, not the fourth-most popular one.  The key in such a scenario is not to add libraries because you want to explore a library; instead, use more common libraries with lots of community support and momentum in the marketplace.  Even then, common libraries can still be dangerous if support for them stops -- I’ve seen that happen, too. And then what happens when you need to upgrade libraries? So, use as few external libraries as possible and when you must go outside of what is provided “in the box” be very careful with your choices. 

·       I often see code written that tries to take advantage of some new or little known feature of a language/platform.  Unfortunately, trying to be clever often leads to more problems than it solves.  While the person who wrote the code will think that it is great and is obvious to everyone else, the reality is often quite different.  If you have your startup poised to launch with some code written using some unknown feature of a framework, what happens when someone else has to take over that code?  Is it going to be clear to them?  Code should be written with a thought that someone else needs to come behind you to make it work, fix a bug, add a feature, or something else.  Code not written with this in mind may see delayed bug fixes, delayed features, or a need for a possible rewrite depending on the nature of what was originally done.   Bottom line: Your code needs to be as simple as possible to solve a problem.

I know it now sounds like I have said that you should not do anything new, try any new library, or do anything besides use what comes in some software installation package. But that's not what I'm implying at all.  If something is needed, then clearly use it.  However, you must understand the choices that you make. It all comes back to risk.

·       How do you minimize/eliminate Technology Risk?  There is always risk out there with everything.  However, the keys to minimizing Technology Risk are:Build your Minimum Viable Product.

·       Add features to your MVP.

·       Be careful with the technology choices that you make.

·       Iterate, iterate, iterate.

·       Keep talking to users.

What About New Choices?

New choices are an interesting thing.  They don’t have track records.  They are by definition new, do not have a community behind them, and do not have any type of track record of success.  How is a developer going to determine what the best mechanism to go forward is?  I’d like to share my views on what I chose to do with two products that came out within a year of each other with the idea that this might help you in choosing what to do in a situation going forward.  Hopefully looking at the decisions that were made will help you make the right decisions and reduce risk in the future for you:

·       Silverlight.  One of the problems of cross-platform libraries is that they have to provide native device features.  Users expect that applications built with a tool will take advantage of all of the features of that platform.  For Silverlight to be successful, it had to have full platform support in various operating systems, including Windows, Mac, and the up and coming mobile platforms of the iPhone and Android. 
My concerns on Silverlight were that it did not seem to have the ability to reach beyond the Microsoft community.  Apple was already making noise that browser plugins were not going to happen in their war on Flash.  How would Silverlight be any different?  Silverlight lacked support from platform vendors outside of Microsoft.  Neither Apple nor Google were going to be involved. Silverlight also presented a non-native UI when it ran outside of the browser.  For these reasons, I did not invest a lot of my time in it beyond customer requests.  That was a good non-investment and blind luck for me.

·       Xamarin.iOS/Monotouch.  While Xamarin.iOS’ success today is obvious, it was not necessarily obvious in 2009 under the wing of Novell.  It was clear that I could write native apps that looked, smelled, and tasted just like every other iOS app back then.  These apps were downloaded by users from the Apple iOS App Store just like every other app.  These apps used what are called native APIs.  A UITableViewController in ObjectiveC looked, smelled, and tasted just like a UITableViewController in Xamarin.  The only difference is that between a developer’s code and the underlying UITableViewController is a C# callable layer and somewhere in there is the Mono/.NET Framework.  The key is that for the users there was no visible difference between an application written with Xamarin.iOS and an application written in ObjectiveC/Swift.  From a user standpoint, there is no difference.  For the users, there was no user risk. 
For the developer, there was a certain degree of risk.  Apple could disallow apps not written in their tools which might have happened due to a one time misunderstanding in the language in Apple’s developer SDK.  Something could happen to Novell, which did happen but got cleaned up.  Any of these issues could have required a developer/company to rewrite the app and to lose some amount of money/value due to this rewrite.  Thankfully, all’s well that ends well.  Xamarin has been going well for the last 4+ years out on its own growing and becoming a better tool each and every day.  Finally in early 2016, Microsoft purchased Xamarin.  This definitely eliminates risk.
What’s the advantage to taking on this risk of using Xamarin?  There are several.  You don’t have to learn a new language or IDE.  This saves significant time.  For me personally, this was months saved in the learning process.  There is no need to switch between languages, which also saves time when development is happening.  With the advent of Xamarin.Android, I can now design my application for iOS, properly segment it, and be on my way to already having an Android application and vice versa.  This was a good (and lucky) choice that I made, and it has resulted in payback.
Note:  I’m not trying to say that I am clairvoyant or brilliant.  I’m just going back through two major decisions I went through in the 2008 – 2011 timeframe.  I have some less than stellar decisions also in my past.

·       To be more general in all of this, the question of risk associated with building web applications with <>.  Tools built on standards tend to not have much user risk associated with them.  Users won’t be able to tell the difference between an app generated with PHP, Ruby on Rails, Node, ASP.NET MVC, or any other framework.  These tools and frameworks don’t have much risk of going away either.  What happens when you are looking at a new tool?  That’s where the problems can come in.  Using a new framework depends on a number of factors and there is no one choice that will eliminate risk.  There are valid reasons to go with something new that depend on your specific situation.

Summary

Risk is all around you.  Your investors and project managers have to deal with risk every day.  For investors, risk can affect their choice as to whether or not to invest.  Project Managers can look at this risk regarding what platforms they choose to use.  Developers also have to deal with risk in the choices that they make.  You need to understand the risk that you are involved with, so that you can properly manage the risk in your given situation.  Good luck with the choices that you make and how they affect your startup.

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

This is Part 3 of my thoughts on the things that can go wrong in a startup.

Beware of Idea People Bearing Contracts

Startup weekend style events are numerous.  They are a great way to flesh ideas out and to build a Minimum Viable Product (MVP).  The idea is that a team of people comes together, works together, and at the end of the event, presents their idea, some market place data, judged by a group of entrepreneurs that have successful started and either have a running company or have successfully exited, and hopefully win the event.  After the event, it is hoped that the team will stay together and push their idea forward.  Granted all of this is a tall order, but startups are hard, not easy.

Unfortunately, there is a disconnect between what the hoped for at startup weekend event, and how people with ideas view them.  Many entrepreneurs that are idea people have a different view.  These people view their idea as the be all and end all.  They don’t want to share that idea with anyone else. However, they are stuck in that they do not have the technical skills to push their idea forward.  Somehow, the idea entrepreneurs have decided that these type of events are a good place for them to find “free labor” for their idea.  I have seen several that have come to these events with contracts that will allow them to get this “free labor” and leave the developers with nothing.  Ultimately, the problem here is that an idea entrepreneur sees:

·       Anyone could steal my idea.  Ideas have little to no value on their own.  Unfortunately, many people think that the idea is everything.  If the idea is everything, they feel that they are within their rights to attempt to keep people from stealing their idea.

·       With the view that the labor is free, there is no differentiator between developers.  One developer is as good, or bad, as any other developer.  The problem that entrepreneurs need to understand is that people do matter. 

·       Based on the concept of no differences between developers, there also tends to be a lack of understanding of the difference between an offshore and onshore development.  Onshore development tends to work better for a startup.  This is due to multiple reasons.  For example, the developer having an intrinsic understanding of the user.  I would expect an Indian developer to understand an Indian consumer.  The same is true in the United States, Europe, China, and everywhere else.  Another issue is timeframes. Startups need quick turnaround. Communication when everyone is not in the same area is hard.  There are advantages to offshore development, however, that is a different article.

Most people at startup events are well meaning people.  Not everyone comes bearing contracts. Unfortunately, I have seen several that do.  From experiences, these never tend to work out.  The people tend to have interesting ideas that have potential.  Good developers tend to not want to work with these people. Instead of an idea that can grow, they end up being stuck by themselves.  If success is a function of the team, they are stuck without a team to move their idea forward.

Who Owns the Code?

Clearly everyone in the startup owns the startup, and they own the code (or graphics, marketing documents, etc).  That’s the popular thinking.  Nothing could be further from the truth.  Barring a contract that states otherwise, and no one ever pays attention until it is too late, code is owned by the person that created it.  This is a common problem in startups.  The code for a startup is not owned by the startup unless it is explicitly handed over to the startup.  

Coachable

How coachable are people?  How coachable are you?  Can you stand the critics of your existing idea?  I can guarantee that people get too attached to their ideas.  I know I do.  Why?  Because it is a product of my brilliance (not really, but you get the idea).  Several instances that I would like to mention:

·       We were at a Saturday morning meeting of our startup years ago.  We were trying to explain to the managing partner that his initial idea needed some tweaking and how to move this forward.  He could not accept that no one wanted his idea that he had crafted 125 pages of documentation into.  While his general idea had merit, we needed to move it about 20 degrees to be right of his target.  He refused and kept saying “It’s not my plan, it’s not my plan.”  Some key changes to his plan, and we would have been winners.  But we couldn’t get him to change his idea, so we were all losers.  It is quite an amazing site to see that some people would rather be wrong than to make a change to their idea and be a big winner.  Ego is an amazing thing.

·       At one startup weekend event, during the discussion we were having regarding business models, she wanted to give everything away for free and to mine the data on the backend for income.  That can definitely remove the “stop sign” for users to use the product, but isn’t really a good mechanism to grow income.  I stated my objection to this and that we needed to have a licensing model to generate income.  I left it at that, so we standing up doing our final presentation on Sunday night, and she goes into the “give it away and mine the data on the backend business model.”  I could not have looked more disappointed as I am running the demo.  When we asked why we only finished third, the feedback from the judges was “horrible business model.”  We wouldn’t have won, but we would have finished second.  Here was someone that had been specifically told, “don’t do that” and did it anyway.

·       People are not going to automatically buy “your genius.”  You have to go out and sell it.  That could be “buying ads” on facebook, google, or somewhere else.  If you are in the SAAS world, its probably shoe leather and knocking on doors.  So, let me get this right, you want to be the “sales” guy, but don’t want to sell?  SMH

·      I often think back and look at the post mortem of “99 dresses.”  What did this person (Nikki Durkin) do that was so bad?  Clearly, she was not a bad person.  She had to have a tremendous level of smarts to get something going.  She got accepted into Y Combinator, which is an accomplishment in and of itself.  But, It seemed that there was a problem, and that problem was that the technical people kept leaving.  Finally, down in the blog post describing their post mortem, it all comes together for me with this paragraph:
I remember one day Marcin joked that I was a control freak, and I was really surprised. I’d never perceived myself that way — I just liked things done a certain way and to a certain standard that matched the vision in my head. When it came to non-99dresses related stuff, I thought I was pretty chill.

This person had several versions of their product all built by different people.  It all came together for me.  She had replaced multiple technical cofounders.  When you are too controlling, you tend to push people away.  Sometimes you have to let go.  It doesn’t matter where your buttons go.  It doesn’t matter if the buttons are blue, red, or green.  Think about solving the problem, not the specifics of the buttons.

The stories go on and on and on.  You have to be all in on a startup.  You have to do things that have worked.  You have to understand your situation.  You have to do things that you may not agree with, if for no other reason than to just try something different to see if the angle has some success.  You have to be coachable, you have to be open to new ideas, and you have to be open to your ideas not being that good.  And yes, that means that my ideas may not be very good.

Summary

Startups have risk.  They have risk for the developer.  The risk needs to be shared by everyone, not just lumped on a single person.  Hopefully, this article has brought out some of them.  Sometimes you may need to just walk away.  It is up to you to decide if the scenario is bad enough.  Good luck on your startup.

Resources

99 Dresses Post Mortem - https://medium.com/female-founders/my-startup-failed-and-this-is-what-it-feels-like-c5d64b3ae96b

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.